DT include files

[Linus Walleij]

On Sun, Jan 12, 2014 at 9:21 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Sunday 12 January 2014, Shawn Guo wrote:

>> , and then code these numbers in their <board>.dts by hand.  It's
>> boring and error prone.  As a comparison, we generate these numbers
>> from reference manual database using a tool and define a macro
>> MX6QDL_PAD_GPIO_17__SPDIF_OUT for these numbers.  The authors only need
>> to find out this macro from imx6q-pinfunc.dtsi and fill it into his dts.
>> Isn't the macro use here helping to ease everyone's life and make the
>> coding less error prone, since the macro is generated from database?
>
> I was under the impression that the generic pinctrl binding was designed
> in a way to let you assign labels to each possible (reasonable)
> configuration so you didn't have get to this level of detail at the
> driver.

There is a binding for handles and states tied to a device.

There is no generic pinctrl binding for the definition of groups
and functions and how they map, i.e. muxing.

The discussion around this ended up with everyone disagreeing
and eventually everybody started writing their own bindings and
have them merged.

There is a generic pin config binding, not everyone uses it,
as they defined their bindings before I got that in place. It
is mostly a requirement for newer drivers.

This Freescale driver does not use the generic binding but
instead it's homebrew thing. The reason being that there was
no generic binding around when it was defined and written.

It is possible to migrate it to generic pinconf, which would
be nice.

> I'm also surprised that you have to know multiple constants
> (mux register, input register, config register offsets) to select a
> particular pin. I would have expected that you could have one constant
> from which the driver is able to compute the other ones.

I might have merged this but I was younger then :-/

Now I don't like the looks of this. I think the DT typically shall not
store register offsets and bitfield information. I think doing
so is taking away the responsibility of the driver knowing the
hardware and moving too close to Open Firmware.

pinctrl-single does store such things, the reason being that
the OMAP people did not even have a datasheet for these regs,
all they get is datafiles from the ASIC engineers, so there is
nothing sensible to encode in the driver in C. But I'm reluctant
also about this driver.

Yours,
Linus Walleij