On 07/31/2014 03:56 AM, Simon Glass wrote:
Hi Stephen,
On 30 July 2014 20:57, Stephen Warren <swar...@wwwdotorg.org
<mailto:swar...@wwwdotorg.org>> wrote:
On 07/30/2014 10:09 AM, Simon Glass wrote:
Hi Stephen,
On 30 July 2014 16:47, Stephen Warren <swar...@wwwdotorg.org
<mailto:swar...@wwwdotorg.org>> wrote:
On 07/30/2014 09:26 AM, Simon Glass wrote:
Hi Stephen,
On 12 June 2014 23:31, Stephen Warren
<swar...@wwwdotorg.org <mailto:swar...@wwwdotorg.org>>
wrote:
On 06/11/2014 10:55 PM, Simon Glass wrote:
...
Hmmm. This email has funny formatting, but hopefully it won't be too
hard to follow.
...
So just define the Tegra GPIO controller as having a single bank.
The fact that U-Boot and Tegra both chose the word "bank" to mean
different things doesn't mean that the U-Boot term has to be forced
to apply to Tegra where the documentation talks about a "bank".
I don't think "bank" is a good description or level of abstraction
anyway; U-Boot should use the term "controller", "chip", or "module"
(which would apply to an entire HW module or GPIO expander chip),
since "bank" is usually an internal implementation detail rather
than something the user cares about. Put another way: all banks in a
controller/chip/module/... would typically use the same
operation/op/callback functions, just with different GPIO IDs or
per-GPIO data, whereas different controllers/chips/modules/... would
use different operation/op/callback functions. It therefore makes
much more sense to abstract at the level of
controller/chip/module/... rather than "bank" level, which is an
internal implementation detail.
Are you saying that 'bank' should be renamed 'chip' and then you would
be happy? Or are you still talking about a separate level of data structure?
My primary objection is:
In Tegra, the GPIO controller should be represented as a single entity
that controls 250 GPIOs, not as a set of separate entities that control
8 or 32 GPIOs each.
Note that I'm talking about what the GPIO controller looks like to
anything outside the driver. Whether the driver internally uses the
concept of banks (or any other name) isn't relevant, since that would be
an entirely hidden implementation detail.
Renaming "bank" to "chip" or "controller" certainly makes sense to me,
but if that's the only change made, it would not address the objection I
just mentioned.
...
The Linux GPIO driver uses the concept of a 'bank', and it doesn't even
match with the TRM. A bank has 32 GPIOs and there are up to 8 banks.
Each bank gets a separate 'struct tegra_gpio_banks'. In no way at they
all lumped together.
That's not quite true.
*Internally* to the driver, there is a struct tegra_gpio_banks, I agree.
As an aside, there really doesn't need to be, since the calculations are
trivial enough that we should just do them for each access, but that's
beside the point.
*Externally* to the driver, there is a single "struct gpio_chip"
registered with the GPIO core. This chip owns/exposes all 250 GPIOs.
That's because in terms of HW, there is a single GPIO controller that
owns all 250 GPIOs.
> I am just trying to make sure that a 'struct
udevice' corresponds to a 'struct tegra_gpio_banks', in the sense that
we are not unnecessarily creating a level of data structure that is
hidden from driver model. For example 'tegra_gpio_banks' would not be
visible to the 'dm tree' command.
I very specifically want U-Boot, just like the kernel, to have a single
driver for the entire GPIO controller.
Whether the internals of that driver have a "struct tegra_gpio_banks" or
not is an implementation detail that has zero impact on the driver
model. As I mentioned above, there's no need for the driver to have a
"struct tegra_gpio_banks"; the register address calculations are trivial
enough that there's no need to divide the GPIO ID -> register address
calculation into two steps (the intermediate step generating this
annoying "bank" ID, which as you mentioned might not even correspond to
what the TRM calls a bank.)
Does it really matter whether we split things into groups of 8 or groups
of 32 or a large group of 224/256?
Yes. Anything external to the GPIO controller driver must see the HW as
it exists and is documented; a single HW module that controls 250 GPIOs.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
