RE: [RFC fixes 0/2] FIX: Renesas RZ series pinctrl driver

[Chris Brandt <Chris.Brandt@xxxxxxxxxxx>]

Hi Jacopo,

On Monday, January 30, 2017, Jacopo Mondi wrote:
> > Note that the I2C pin need to be configured at "bi-directional" but
> > there is no way to specify that from DT, so that has to be added as a
> parameter.
> 
> That's something I would like to discuss quite soon.
> One general thing I would like is having the so-called "additional
> parameters" part of the SoC driver module, as my gut feeling is that
> different PFC hw requires different configuration options.

In the API I used for the current RZ/A1 BSP, I used an extra parameter
to pass in any non-normal settings.


> In example, the RZ/A1 SoC requires the input/output direction of the pin
> to be specified even when the alternate function is supposed to drive it
> (in order to enable/disable input buffer). The same applies to bi-
> directional port control as you pointed out in your example (bi-
> directional enables input buffer, but that's a consequence of how hw works
> there).
> 
> I'm almost sure the same won't be required by all existing and forth-
> coming Renesas SoCs with a pin-based PFC hardware, but maybe other
> parameters I cannot think of right now will have to be specified instead.

I would guess for one reason or another, there is always some exception
in the hardware manual when it comes to pins settings. Meaning, there are
restrictions in the I/O pad circuits that the HW designers find it easier
to tell the SW guys to deal with it instead of trying to make it 'automatic'
in HW.
So...you'll always have the need for an extra parameter.


> If we want to keep the configuration flags SoC-specific, the most easy way
> to pass them down from core module to SoC module would be compressing the
> alternate function number and other configurations in a single u32.
> 
> In that case the dts will look like:
> 
> renesasa,rz-pins = <BANK PORT (ALTERNATE_FUNC_# | IO_MODE | DIRECTION)>;
> 
> We could even add a parameter to separate ALTERNATE_FUNCTION from the
> additional configurations, but I don't see any advantage in doing this at
> the moment.

As I said, I made "additional configs" a separate parameter, but combining
it with ALTERNATE_FUNC_# is fine with me. I have not seen an SoC that allowed
any more than 8 different functions per pin, so you have lots of bits
in u32 in order to set flags bits.

However, as already mentioned by Geert, "ALTERNATE_FUNC_#" is too long of
a name. Just "ALT_#" is fine.

    renesasa,rz-pins = <BANK PORT (ALT_# | IO_MODE | DIRECTION)>;

Geert's suggestion was to just use the actual number (1-8), ALT_# might make
it easier to decode if you are combining multiple things into a single u32.

There is one more idea....but I heist to suggest it.
You just pass in the port and alternate function number, and you do a lookup
table for settings such as bi-direction or port direction register.
You only put into the table the pin settings that are "not normal".

The benefit is that the user doesn't have to know what pins needs what special
tweak/flag/setting....but of course it start to make the driver more complex.



Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html