From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] Driver Model and DTS Parsing
Date: Thu, 12 Jun 2014 16:31:30 -0600 [thread overview]
Message-ID: <539A2A42.80903@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ10O5cLYhYfRhJ3mTUcWNfenct0-bzNqoX6C9tGbeUdYQ@mail.gmail.com>
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.
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.
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.
next prev parent reply other threads:[~2014-06-12 22:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 14:49 [U-Boot] Driver Model and DTS Parsing Jon Loeliger
2014-06-03 1:26 ` Simon Glass
2014-06-03 13:39 ` Jon Loeliger
2014-06-03 16:04 ` Simon Glass
2014-06-03 16:33 ` Stephen Warren
2014-06-12 4:55 ` Simon Glass
2014-06-12 22:31 ` Stephen Warren [this message]
2014-07-30 15:26 ` Simon Glass
2014-07-30 15:47 ` Stephen Warren
2014-07-30 16:09 ` Simon Glass
2014-07-30 19:57 ` Stephen Warren
2014-07-31 9:56 ` Simon Glass
2014-07-31 18:04 ` Stephen Warren
2014-08-04 10:22 ` Simon Glass
2014-08-04 17:38 ` Stephen Warren
2014-08-04 20:21 ` Simon Glass
2014-07-31 21:58 ` Simon Glass
2014-07-31 22:54 ` Stephen Warren
2014-08-01 15:42 ` Jon Loeliger
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=539A2A42.80903@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox