Re: [PATCH 2/2] Make non-linear GPIO ranges accesible from gpiolib

[Stephen Warren]

On 06/25/2013 08:56 AM, Linus Walleij wrote:
> On Fri, Jun 21, 2013 at 11:17 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>> On 06/20/2013 05:57 AM, Christian Ruppert wrote:
> 
>>> Your remark seems to reflect one of the following two hardware
>>> architectures:
>>>
>>>                                                      +- SPI
>>>                  Physical pins --- GPIO --- pinctrl -+- I2C
>>>                                                      +- mmc
>>
>> (that's diagram 1)
>>
>>>
>>>                                 +- GPIO
>>>                  Physical pins -+           +- SPI
>>>                                 +- pinctrl -+- I2C
>>>                                             +- mmc
>>
>> (that's diagram 2)
>>
>>> TB10x hardware architecture:
>>>
>>>                                             +- SPI
>>>                  Physical pins --- pinctrl -+- I2C
>>>                                             +- mmc
>>>                                             +- GPIO
>>
>> (that's diagram 3)
>>
>> No, I was thinking of diagram 3 above. I'm not sure if diagrams (1) or
>> (2) are common or exist?
> 
> The U300 pin controller is obviously of type (1) as it can spy on
> the signals.

U300 HW might be diagram (1) - I can't say since I'm not familiar with
the HW. However, the fact that GPIO can spy on signals in no way at all
implies that the HW must conform to diagram (1).

In diagram (2), the pins are routed to both the GPIO and pinctrl module,
so there's no reason why GPIO couldn't spy on any input signals there too.

Even in diagram 3, GPIO may be able to spy. The issue is how the
"inbound" muxes work.

For output signals from HW modules through the pinctrl HW to the pins,
there's likely a plain n:1 mux that selects a single signal and drives
it out.

For input signals, there are still some choices; you might have a 1:n
mux that only drives 1 single HW module's input signals from the pins,
or you may simply wire the input pin through to all the possible HW
modules in parallel on the input side, or you may always wire the input
pin to the GPIO HW module, but have a 1:n mux for the dedicated HW
modules so that (at most) one of those is driven by the pin, etc.

For reference, the Tegra HW is diagram (3), although actually the GPIO
module has the register bits that select between GPIO and mux-function
for each pin! The signals that control this are fed from the GPIO
register bits into input signals on the pinmux HW, which does all the
actual muxing. The input path muxing is set up so that without affecting
the pinmux programming, the GPIO module can spy on any input signal,
although while doing so, it disconnects the input pin from the dedicated
mux function, thus potentially causing some disruption.

> The Nomadik pin controller is basically type (2).
> 
> Maybe this is part of the explanation to why we sometimes tend
> to talk past each other :-D
> 
> (I would replace the string "pinctrl" with "pinmux" above,
> as I just did in my documentation patch adding these
> diagrams.)

--
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/