From: Stephen Warren <swarren@wwwdotorg.org>
To: Matthias Klein <matthias.klein@linux.com>
Cc: linux-rpi-kernel@lists.infradead.org, lee@kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+
Date: Thu, 06 Nov 2014 12:01:23 -0700 [thread overview]
Message-ID: <545BC583.407@wwwdotorg.org> (raw)
In-Reply-To: <545BBAA4.90407@linux.com>
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.
next prev parent reply other threads:[~2014-11-06 19:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-05 23:45 [PATCH v2] ARM: bcm2835: add device tree for Raspberry Pi model B+ Matthias Klein
2014-11-06 5:11 ` Stephen Warren
2014-11-18 21:15 ` Matthias Klein
2014-11-06 5:29 ` Stephen Warren
2014-11-06 18:15 ` Matthias Klein
2014-11-06 19:01 ` Stephen Warren [this message]
2014-11-06 19:36 ` Noralf Tronnes
2014-11-07 4:22 ` Stephen Warren
2014-11-07 16:20 ` Noralf Tronnes
[not found] ` <CAE8Q9tBDxq9W=Vh0LRCRNR+Dj+5PrWyzK+GBdMDM=1kq84mFTA@mail.gmail.com>
2014-11-07 17:12 ` Gordon Hollingworth
2014-11-08 6:17 ` Stephen Warren
2014-11-08 8:03 ` Gordon Hollingworth
2014-11-08 6:12 ` Stephen Warren
2014-11-19 15:29 ` Lee Jones
2014-11-19 17:08 ` Stephen Warren
2014-11-19 17:29 ` Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545BC583.407@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=matthias.klein@linux.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.