[U-Boot] Driver Model and DTS Parsing

[Simon Glass]

Hi Stephen,

On 12 June 2014 23:31, Stephen Warren <swarren at wwwdotorg.org> wrote:
> On 06/11/2014 10:55 PM, Simon Glass wrote:
> ...
>> Tegra doesn't have much in the device tree for GPIOs - it seems to be
>> all hard-coded in the software. So I ended up with the code you saw
>> which just iterates over a known number of banks, creating a device
>> for each.
>
> That still sounds wrong. Tegra HW has a single GPIO controller that
> exposes a bunch of GPIOs. It isn't logically divided into banks or any
> other construct that is multi-level  Although the naming of the
> individual GPIOs does call something a bank, that's just a name of a
> register, not separate HW blocks. It's just going to be confusing to
> users if the U-Boot representation doesn't match what the HW actually has.

I'm getting back to this as I just re-issued the series.

I don't see the mismatch you are referring to here. U-Boot people are
used to seeing GPIOs as named banks, and the Tegra TRM uses bank names
also.

>
> There's zero extra indirection caused by SW correctly describing the HW
> as a single bank. I have absolutely no idea what you mean my extra
> indirection here; any time there is a driver for a GPIO, you call a
> function to set a GPIO. That doesn't change based on whether there are
> 32 or 1 GPIO controller drivers.  The only difference is how many
> drivers you have to search through to find the right one. For Tegra at
> least, I'm arguing for 1 driver to match the 1 HW module.

OK let me explain a bit more.

At the moment, the GPIO uclass supports a single GPIO bank, defined as
something that has a name, like A, or B. Within that bank there can be
several individual GPIO lines. This is what the Tegra TRM refers to as
A0, A1, B0, B1, etc.

Should we wish to support banks A-Z, AA, BB, etc. all as a single GPIO
device, we would need to redo the uclass to support this. It would
need to support having more than one bank (a one-to-many relationship)
and thus we would need a second-level data structure to hold the bank
names of each bank. In that case each GPIO device would hold a list of
banks, each bank having a set of GPIOs. The 'gpio' command would need
to query the device for the list of available banks and use that in
decoding its command line parameters.

The list of banks is the secondary data structure that I am referring
to, and is what I would like to avoid for now, given that in U-Boot
devices can have children. It may be in the future that we end up
going that way, but so far I would prefer to avoid secondary data
structures and keep things really simple.

>
> DT is supposed to represent the differences between boards more than the
> differences between SoCs. Anything that the driver can reasonably derive
> from the compatible value shouldn't be represented in the DT. That's why
> the Tegra GPIO DT node just has a compatible value, register address,
> and list of interrupts. Nothing more is required. If anything else were
> put in DT, you'd end up just wasting time parsing from DT static data
> that could just be in the driver.

This is fine, although it is entirely a trade-off between code and
data. Some SoCs use the device tree to specify differences between the
SoCs (e.g. pinmux on exynos) and some don't. There doesn't seem to be
a hard-and-fast rule. In this case I was just expressing the fact that
the device tree is not really used for the GPIO devices on Tegra.

Regards,
Simon