Hi Laurent,
On 11/01/2017 17:31, Laurent Pinchart wrote:
Hi Jacopo,
[snip]
I was wondering if that should not be be turned into something more
similar to the pinctrl-single defined ABI. In that case it would look
like this (please excuse the pseduo-dts syntax here)
scif2_pins: serial2 {
renesas,pin = <3, 2, MUX_MODE4, PIN_CONFIG_OPTIONS,
3, 0, MUX_MODE6, PIN_CONFIG_OPTIONS>
This should just be "pin", not "renesas,pin".
};
Yes, I believe that should be done, especially given that the datasheet for
the SoC is public. For other SoCs the current PFC driver model exposes the
information needed to configure pin muxing even if you can't access the
datasheet, which is an option that I'd hate losing.
Just to point out that this proposed change won't affect the existing
R-Car devices, but would apply to RZ/A-like devices currently not
supported and which may appear in future (and according to Chris, to
some old SH ones which no one wants to touch ;P )
I'm thinking about something like
drivers/pinctrl/sh-pfc/ (which would be better re-named as rcar-pfc)
drivers/pinctrl/rz-pfc/
But that's a big change that may upset some people here :)
I'm under the impression that pinctrl-single would almost do, if not for
the write function bit, that for OMAP platform results in a write to a
single register, while (for RZ/A at least) we have to spread it on a
bunch of different registers.
That's correct, but a pinctrl-single-like driver could be implemented
relatively easily without all the data tables. We might still need some data
if we want to validate DT entries though, for instance to store the valid pin
config and/or options for each pin.
A big difference from what pinctrl-single does and what the table-based
approach does is that it creates groups, pins and functions at run-time,
parsing the dts...
There's indeed quite some code there for doing this, but it does not
perform any validation of what the dts describes.
Maybe we can skip all that part (parsing and run-time generation of
groups, pins and function) using tables, and adopt a pin-oriented ABI
that would allow us to specify in the dts the function and the per-pin
configuration that would look more natural for this kind of devices.
As a final note: maybe we need to decide what to do with this series,
people is spending time reviewing it, and I've just sent v2 out. If we
want to go in a different direction, we should stop here :)
Thanks
j
