Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+
From: Stephen Warren
Date: Thu Nov 06 2014 - 14:01:24 EST
On 11/06/2014 11:15 AM, Matthias Klein wrote:
Am 06.11.2014 um 06:29 schrieb Stephen Warren:
I guess we should have separate device trees for those, since there are
some differences in the GPIO and I2C channel usage. That'd leave us with:
bcm2835-rpi-b.dts (Pin3=GPIO0, Pin5=GPIO1, Pin13=GPIO21, I2C-0)
bcm2835-rpi-b-rev2.dts (Pin3=GPIO1, Pin5=GPIO2, Pin13=GPIO27, 12C-1)
>
I think for these differences separate device trees are not needed.
These pins are all at the moment configured as ALT0.Both I2C buses are
configured for I2C,
therefore I doesn't matter which one is wired to the gpio header.
At the moment perhaps there's not a lot of difference between the board.
However, e.g. the board ID pins on the early boards are connected to
pull-up/down resistors, and hence could be represented in DT as specific
named GPIOs or not, depending on whether the board has board ID pins.
Similarly, we should only enable the I2C controllers on a particular
board if there's any possibility of a user connecting something, which
is only true if that particular I2C controller is routed to an IO
connector (or on-board device).
But for clarity it would be better to have a separate device tree for
each model.
So yes, I think we should move to separate DTs for each incompatible
model, so that if/when we actually want to make the DT content different
between them, we already have separate DTs in place to do that. That
will allow use to update any bootloaders to choose the right DT now,
rather than right when we really need it done already:-)
When a gpio signal (which is configured in device tree as ALT0) is used
as e.g. plain gpio output, does the kernel the reconfiguration from ALT0
to gpio output?
IIRC, the kernel GPIO driver sets the pinmux to GPIOin/GPIOout based on
gpio_request() calls.
Or must the gpio signal be configured as output in the device tree?
It doens't have to be. That said, if we *know* that a particular GPIO is
used as a GPIO rather than a special function, there's probably no harm
just putting that setting right into the DT.
Is is possible to set at the brcm,function/brcm,pins gpio definition
also the voltage level of an gpio output for e.g. the LAN_RUN signal?
No. The value on a GPIO pin can only be selected by code. For pins such
as LAN_RUN that don't have code controlling them, you can get away with
setting the pin as input/tri-state with a pull-up/pull-down to get the
desired state.
How do we want to continue?
Is my patch OK, or should I try to write a device tree for every model
where every gpio signal is defined?
I think the patch is fine for now; my thoughts were more about the need
to send additional patches to add more DTs later.
--
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/