Adding my 2 cents here: On Wednesday, March 29, 2017, jacopo wrote: > > > If you really do we may need to go for u64 but ... really? Is there > > > a rational reason for that other than "we did it like this first"? > > > > > > I do not understand the notion of "flags" here. I hope that is not > > > referring > > > > Flags refers to BI_DIR, SWIO_IN, and SWIO_OUT, from > > https://patchwork.kernel.org/patch/9643047/ > > > > 32-bit should be enough to cover pins, function, and flags. > > > > Geert already replied, but to avoid any confusion I'll try to remove from > driver the use of "pin config" when referring to this three flags, which > are just additional informations the pin controller needs to perform pin > muxing properly. They're not related the standard pin config properties > (pull-up/down, bias etc.. actually our hardware does not even support > these natively) > > > > to pin config, because I expect that to use the standard pin config > > > bindings outside of the pinmux value which should just define the > > > pin+function combo: > > > > > > node { > > > pinmux = <PIN_NUMBER_PINMUX>; > > > GENERIC_PINCONFIG; > > > }; > > > > > > Example from Mediatek: > > > > > > i2c1_pins_a: i2c1@0 { > > > pins { > > > pinmux = <MT8135_PIN_195_SDA1__FUNC_SDA1>, > > > <MT8135_PIN_196_SCL1__FUNC_SCL1>; > > > > If we follow this example, then we can list all combinations in > > include/dt-bindings/pinctrl/r7s72100-pinctrl.h, instead of creating > > the value by combining the bits using a macro where we need it in the > DTS. > > > > It's gonna be a long list, though... > > > > I'm strongly in favour of something like > pinmux = <PIN(1, 4) | FUNC# | FLAGS>, .... ; > > opposed to > pinmux = <PIN1_4_FUNC#_FLAGS>, ... ; I agree. I like "<PIN(1, 4) | FUNC# | FLAGS>". > Not only because it will save use from having a loong list(*) of macros > that has to be kept up to date when/if new RZ hardware will arrive, but > also because of readability and simplicity for down-stream and BSP users. > Speaking of which, I would like to know what does Chris think of this. The list of macros would be very long, especially against the different packaging version of the RZ/A1 series. 11 ports, 16-pins for each port, 8 different function options for each pin....2 different package/pin variations. And at the end of the day....there is no benefit for the user over just using a macro. A little about "this controller" for the RZ/A1: In my opinion it's a one-shot usage. I don't foresee future RZ/A SoCs using this exact pin controller. The reason for the "FLAGS" is to work around a quirky hardware design (in my opinion). However, future RZ/A SoCs will use a 'similar' type controller where each pin has 8 function options (but the FLAGs won't be needed anymore...as far as I can see...). So I foresee the DT interface staying more or less the same, but the underlying register setup in the driver Will change (become more simple). Now...if we can only convince the R-Car guys to move to a more simple pin-mux controller... Chris
