From: javier Martin <hidden> Date: 2012-07-27 07:59:21
Hi,
we are trying to support pinctrl for i.MX21, i.MX1 and i.MX27.
In these chips, gpio and pinctrl use the same HW memory area
registers. This means that we have to request the same memory area
from two different drivers (gpio and pinctrl) but we don't know how to
do that.
A similar example available is mxs, but it only works with device
tree, so this problem is avoided. However, some of these chips
(i.MX21, i.MX1...) don't support device tree yet, so we need to
provide backwards compatibility.
What is the right way to request the same memory region from two
different drivers? Moreover, how can we guarantee that there won't be
any conflicts when accessing these shared resources?
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
On Fri, Jul 27, 2012 at 13:29:21, javier Martin wrote:
Hi,
we are trying to support pinctrl for i.MX21, i.MX1 and i.MX27.
In these chips, gpio and pinctrl use the same HW memory area
registers. This means that we have to request the same memory area
from two different drivers (gpio and pinctrl) but we don't know how to
do that.
A similar example available is mxs, but it only works with device
tree, so this problem is avoided. However, some of these chips
I am curious as to how device tree solves the access issues for
a shared resource.
(i.MX21, i.MX1...) don't support device tree yet, so we need to
provide backwards compatibility.
What is the right way to request the same memory region from two
different drivers? Moreover, how can we guarantee that there won't be
any conflicts when accessing these shared resources?
For a few registers this might be an overkill but MFD comes to mind.
Regards,
Vaibhav B.
From: Thomas Petazzoni <hidden> Date: 2012-07-27 09:19:58
Le Fri, 27 Jul 2012 09:59:21 +0200,
javier Martin [off-list ref] a ?crit :
Hi,
we are trying to support pinctrl for i.MX21, i.MX1 and i.MX27.
In these chips, gpio and pinctrl use the same HW memory area
registers. This means that we have to request the same memory area
from two different drivers (gpio and pinctrl) but we don't know how to
do that.
A similar example available is mxs, but it only works with device
tree, so this problem is avoided. However, some of these chips
(i.MX21, i.MX1...) don't support device tree yet, so we need to
provide backwards compatibility.
What is the right way to request the same memory region from two
different drivers? Moreover, how can we guarantee that there won't be
any conflicts when accessing these shared resources?
I would say there is no right way. If the pinctrl/gpio registers are
really intermixed and belong to the same region, then there should be
only one driver that requests this region and that implements both the
pinctrl and gpio features.
See the drivers/pinctrl/pinctrl-coh901.c driver for example. It
implements both the pinctrl and the gpio logic.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
From: javier Martin <hidden> Date: 2012-07-27 09:33:13
On 27 July 2012 11:19, Thomas Petazzoni
[off-list ref] wrote:
Le Fri, 27 Jul 2012 09:59:21 +0200,
javier Martin [off-list ref] a ?crit :
quoted
Hi,
we are trying to support pinctrl for i.MX21, i.MX1 and i.MX27.
In these chips, gpio and pinctrl use the same HW memory area
registers. This means that we have to request the same memory area
from two different drivers (gpio and pinctrl) but we don't know how to
do that.
A similar example available is mxs, but it only works with device
tree, so this problem is avoided. However, some of these chips
(i.MX21, i.MX1...) don't support device tree yet, so we need to
provide backwards compatibility.
What is the right way to request the same memory region from two
different drivers? Moreover, how can we guarantee that there won't be
any conflicts when accessing these shared resources?
I would say there is no right way. If the pinctrl/gpio registers are
really intermixed and belong to the same region, then there should be
only one driver that requests this region and that implements both the
pinctrl and gpio features.
See the drivers/pinctrl/pinctrl-coh901.c driver for example. It
implements both the pinctrl and the gpio logic.
Thank you, that was very useful.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
On Fri, Jul 27, 2012 at 09:03:33AM +0000, Bedia, Vaibhav wrote:
On Fri, Jul 27, 2012 at 13:29:21, javier Martin wrote:
quoted
Hi,
we are trying to support pinctrl for i.MX21, i.MX1 and i.MX27.
In these chips, gpio and pinctrl use the same HW memory area
registers. This means that we have to request the same memory area
from two different drivers (gpio and pinctrl) but we don't know how to
do that.
A similar example available is mxs, but it only works with device
tree, so this problem is avoided. However, some of these chips
I am curious as to how device tree solves the access issues for
a shared resource.
Although pinctrl and gpio share the same IO region, they are accessing
different registers, so there should be no access issues.
--
Regards,
Shawn
we are trying to support pinctrl for i.MX21, i.MX1 and i.MX27.
In these chips, gpio and pinctrl use the same HW memory area
registers. This means that we have to request the same memory area
from two different drivers (gpio and pinctrl) but we don't know how to
do that.
A similar example available is mxs, but it only works with device
tree, so this problem is avoided. However, some of these chips
(i.MX21, i.MX1...) don't support device tree yet, so we need to
provide backwards compatibility.
What is the right way to request the same memory region from two
different drivers? Moreover, how can we guarantee that there won't be
any conflicts when accessing these shared resources?
I think the method that Linus Walleij usually recomments for dealing with
this is to create a combined gpio+pinctrl driver that lives in
drivers/pinctrl but registers to gpiolib as well.
Have a look at drivers/pinctrl/pinctrl-nomadik.c for an example of this.
Arnd
On Sat, Jul 28, 2012 at 19:37:54, Shawn Guo wrote:
On Fri, Jul 27, 2012 at 09:03:33AM +0000, Bedia, Vaibhav wrote:
quoted
On Fri, Jul 27, 2012 at 13:29:21, javier Martin wrote:
quoted
Hi,
we are trying to support pinctrl for i.MX21, i.MX1 and i.MX27.
In these chips, gpio and pinctrl use the same HW memory area
registers. This means that we have to request the same memory area
from two different drivers (gpio and pinctrl) but we don't know how to
do that.
A similar example available is mxs, but it only works with device
tree, so this problem is avoided. However, some of these chips
I am curious as to how device tree solves the access issues for
a shared resource.
Although pinctrl and gpio share the same IO region, they are accessing
different registers, so there should be no access issues.
Ok that makes sense. Thanks for clarifying.
Regards,
Vaibhav B.
On Sun, Jul 29, 2012 at 4:19 PM, Arnd Bergmann [off-list ref] wrote:
On Friday 27 July 2012, javier Martin wrote:
quoted
What is the right way to request the same memory region from two
different drivers? Moreover, how can we guarantee that there won't be
any conflicts when accessing these shared resources?
I think the method that Linus Walleij usually recomments for dealing with
this is to create a combined gpio+pinctrl driver that lives in
drivers/pinctrl but registers to gpiolib as well.
Yepps.
Have a look at drivers/pinctrl/pinctrl-nomadik.c for an example of this.
What this and many other drivers run into is the problem of mappings
between GPIOs and pin controller ranges (GPIO ranges).
Currently these are registered by the pin controller and may need
access to the struct gpio_chip which creates an "interesting"
probe order problem. But it can be solved (in not-so-elegant ways).
Long term we want to turn this upside down and have the GPIO
driver portion register it's ranges to the pin controller instead,
using local range GPIO numbers.
Yours,
Linus Walleij