RE: [PATCH 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux