Hi Jacopo, > > Additionally, according to the RZ/A1 hardware manual: > > "When the output buffer is enabled and the PBDCn.PBDCnm bit is 1, the > > input buffer is enabled regardless of this register setting." > > > > Yes, I used INPUT_EN to drive PBDC.. > My assumption was that "users" would have had to decide when a pin was > acting as input, when describing it in dts, rather than having to deal > with the TRM and learn what bidirectional control is and is consequences > (particularly, that it enables the input buffer). > > But since I guess this whole driver assumes more detailed knowledge on the > hardware compared to group-based ones, I think using BI_DIR is fine here The reality is, I will be providing DT examples and people will just follow them like they copy/paste the code from my rskrza1-board.c file today. Of course they still have to look up the 'alternative function' number in the Hardware manual, but that's in an easy to read table. > > So in summary, this is how I think things should look in the DT: > > > > Example of a 'normal' pin (most of the pins). > > /* P3_0 as TxD2; P3_2 as RxD2 */ > > renesas,pins = <PIN(3, 0) 6>, > > <PIN(3, 2) 4>; > > Just to make sure I'm following you: why RxD2 (P3_2) is not marked as > BI_DIR? Because it doesn't have to be. The pin controller itself knows how to set it up itself as soon as you set the PIPC. > I would have expected to have the flag specified here, as it > requires PIBC enabled (and as you said, BI_DIR drives PBDC that enables > PIBC consequentially) PIBC (Port Input Buffer Control) is only valid when you are in GPIO input port mode (PMCn.PMCnm = 0 and PMn.PMnm = 1). The reality is, it would be nice if the controller could magically know how to set all the pins direction, buffers and such depending on their function, but there were some that needed an extra signals to be manually set (whether it makes sense or not). I guess that's the consequence of mixing-and-matching IP from different product lines. Oh well, we just fix it all in software, right? ;) I'd rather this than the PFC that's in the R-Car....which I think is the result of trying to make it smarter and just ended up making it more complicated. Cheers Chris -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
