Re: [PATCH 1/2] pinmux: Add TB10x pinmux driver

[Linus Walleij]

On Thu, May 2, 2013 at 8:49 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> On 04/29/2013 10:17 AM, Christian Ruppert wrote:
>>>
>>> So if this is what you want to achieve, just use the same number
>>> as in your datasheet in the pin number -> problem solved.
>>
>> The problem is that we must support several products which are basically
>> different packaging options of the same chip (or simplified versions
>> thereof). Not all of those products will have the same number of pins
>> and as a consequence, data sheet pin numbering will also be different.
>> The port names are going to remain the same for all products, however.
>> Some of the ports are just not going to be physically available in some
>> or the products. Sorry if that wasn't clear from my previous mail.
>
> It sounds like you can use the exact same numbering scheme for all the
> different packaging options; it's just that some of the pin numbers
> simply won't exist on some of the packaging options, so while defined by
> the DT binding, it simply won't make sense to use them?
>
> Certainly, Tegra20 has two packaging options, and the pinctrl driver for
> it has zero knowledge of this. Perhaps we're just lucky though. I guess
> the Tegra TRM doesn't define any "Pin number" (just "pin name") for the
> pins, so there's no possibility of the same "number" meaning different
> things in the two packages, so perhaps we're just getting lucky here.

I am certain it must be possible to come up with something reasonable
here, especially since this is using the device tree.

In U300 we had something like 4 different packaging types, all with
different names on the pins, however I could avoid the entire
issue by using pad numbers instead, i.e. the numbers of the pads/fingers
on the silicon die inside the chip.
(Documentation/pinctrl.txt contains hints on this.)

It seems like your situation is similar.

And since you work for Abilis I assume you can access such low-level
documentation and come up with a numbering scheme based on
something that does not vary with packaging.

And if you can't, and since you're using device tree, come up with
a per-packainging pin numbering, put it into a special .dtsi file that
you layer over the core SoC .dtsi file just to get these numbers,
and then use the apropriate packaging .dtsi in yout eventual
machine .dts file.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/