On Wed, May 29, 2013 at 02:21:05PM +0200, Linus Walleij wrote:
> On Fri, May 24, 2013 at 1:50 PM, Christian Ruppert
> <christian.ruppert@xxxxxxxxxx> wrote:
>
> > I haven't understood how to associate GPIOs to
> > other functions, however: Our hardware pin controller makes GPIO pins
> > available depending on the configuration of the non-GPIO interfaces.
> > This means that in many configurations, GPIO banks are only partially
> > available because some pins are used for other purposes. We can't expect
> > our customers to manually change the pin assignments in the device tree
> > in order to take this into account for every PCB.
>
> But what is it your customers do when customizing a board then?
Ideally, they just select the pin functions they would like to use on
their PCB using the phandle mechanism outlined in
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt.
We will prepare the nodes to point to in our SOC .dtsi files. Obviously,
customers will look at these files, in particular the nodes they point
to. The simpler these nodes are (and the easier to understand) the
better.
> Part of the promise of the device tree is to make it easy for downstream
> users to customize the kernel, *especially* for different boards/systems
> using the same SoC, for example. It is very much intended as a
> customization tools for embedded developers getting boards from
> a chipset vendor.
Yes, this is our understanding as well. This is why we would like to
avoid confusion through the exposure of obscure number spaces, even
if a customer is not supposed to modify them.
Ease of use is also the reason why I added the gpio-base property to the
original driver: Finding out the global GPIO number to use in
/sys/class/gpio for a given GPIO of a given bank seems to be a recurring
headache for our customers and the definition of the bank's base number
in the device tree is an attempt to improve this situation. I am looking
forward to the patch you said Alexandre is working on which will
probably be a much better solution.
> Maybe I don't understand what is meant by changing the pin
> assignments above ...
Every pin can have exactly one function at a time and is thus assigned
to that function. Ideally, conflicts are cleanly managed in the pinmux
driver and an error message is generated so customers can understand why
something doesn't work and how to fix it.
Greetings,
Christian
--
Christian Ruppert , <christian.ruppert@xxxxxxxxxx>
/|
Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri
_// | bilis Systems CH-1228 Plan-les-Ouates
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
