[PATCH 0/2] Enable cc8540 pinctrl DT for uart and i2c v2

[PATCH 0/2] Enable cc8540 pinctrl DT for uart and i2c v2

[Gabriel Fernandez]

From: Gabriel Fernandez <gabriel.fernandez@st.com>

Theses patches enable ccu8540 pintctrl DT for uart and i2c
Modifications from first version:
	- supress &pinctrl_dbx500 phandle.
	- add pintctrl { compatible = "stericsson,db8540-pinctrl"; ...
	- cosmetics.

Gabriel Fernandez (2):
  ARM: u8540: Add Pinctrl Device Tree settings for uart0, uart2
  ARM: u8540: DT: Set pinctrl mapping to i2c0,1,2,4 & 5

 arch/arm/boot/dts/ccu8540-pinctrl.dtsi     | 196 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/ccu8540.dts              |  45 +++++++
 arch/arm/boot/dts/ste-nomadik-pinctrl.dtsi |  95 ++++++++++++++
 include/dt-bindings/pinctrl/nomadik.h      |  36 ++++++
 4 files changed, 372 insertions(+)
 create mode 100644 arch/arm/boot/dts/ccu8540-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/ste-nomadik-pinctrl.dtsi
 create mode 100644 include/dt-bindings/pinctrl/nomadik.h

-- 
1.8.1.1

Re: pinctrl:when two device use the same pin

[Linus Walleij]

On Thu, Jun 13, 2013 at 4:43 AM, xulinuxkernel <xulinuxkernel@gmail.com> wrote:

> I am using the kernel pinctrl subsystem, and I have a problem,when two
> devices use the same pin,how about the consumer devices handle the conflict
> pins? some thing like this:
> assumer the device A and B use the same pin pin0,
> device A:                                                            device
> B calling the API
> devm_pinctrl_get_select(&dev_a,"dev_a");
> devm_pinctrl_get_select(&dev_b,"dev_b");
> then the deviceB should be return error,or wait for device A  release pin0?
> like schedule()? or something else?

So you have one of two problems:

- You are trying to probe two drivers on the system, both making
  use of the same pins *at the same time*, this would obviously
  be plain wrong. In this case the solution would be not to add
  the unused device in the first place.

- You are using the same pins with two different devices at
  runtime, i.e. dev A and B actually use the same pins on the
  same one running system.

I assume it's the latter situation, which appear in a few practical
situations, such as a SD card slot being reconfigured into a debug
port becuase we want to get some non-SD-type data out on the
SD card connector. (We have this on the ux500.)

The solution to this situation is described in Documentation/pinctrl.txt
under the heading "Runtime pinmuxing", below is a copy but I think
the basic problem is that you rely on devm_pinctrl_get_select()
to be done at probe instead of retrieveing the pinctrl state handlers
and activeley switching between them at runtime using
pinctrl_select_state() which is what you should do.

Device A should have two states: one which is not using any
pins, and one where it's actively using it's pins, and the same
for device B. At runtime, the drivers shall just activate the state
using the pins when they actually do that.


Copy from Documentation/pinctrl.txt:

Runtime pinmuxing
=================

It is possible to mux a certain function in and out at runtime, say to move
an SPI port from one set of pins to another set of pins. Say for example for
spi0 in the example above, we expose two different groups of pins for the same
function, but with different named in the mapping as described under
"Advanced mapping" above. So that for an SPI device, we have two states named
"pos-A" and "pos-B".

This snippet first muxes the function in the pins defined by group A, enables
it, disables and releases it, and muxes it in on the pins defined by group B:

#include <linux/pinctrl/consumer.h>

struct pinctrl *p;
struct pinctrl_state *s1, *s2;

foo_probe()
{
        /* Setup */
        p = devm_pinctrl_get(&device);
        if (IS_ERR(p))
                ...

        s1 = pinctrl_lookup_state(foo->p, "pos-A");
        if (IS_ERR(s1))
                ...

        s2 = pinctrl_lookup_state(foo->p, "pos-B");
        if (IS_ERR(s2))
                ...
}

foo_switch()
{
        /* Enable on position A */
        ret = pinctrl_select_state(s1);
        if (ret < 0)
            ...

        ...

        /* Enable on position B */
        ret = pinctrl_select_state(s2);
        if (ret < 0)
            ...

        ...
}

The above has to be done from process context. The reservation of the pins
will be done when the state is activated, so in effect one specific pin
can be used by different functions at different times on a running system.


Yours,
Linus Walleij

Re: Re: pinctrl:when two device use the same pin

[Linus Walleij]

On Sat, Jun 15, 2013 at 2:10 PM, xulinuxkernel <xulinuxkernel@gmail.com> wrote:

> In my company,on the chip, the spi nor flash and nand flash use the same
> four pins.In this case,it must be different devices and different drivers.
> In the "Runtime pinmuxing", I think it is one device has two different
> state.

This does not sound like runtime pin muxing.

This sounds like you have *either* a NOT flash *or* a NAND
flash connected to your chip, not both NOR and NAND at the
same time.

Just do not register the device nor add the pinctrl tables
for the one that is not used on a certain target system.
Atleast do not add the pinctrl tables for NOR when using
NAND and vice versa.

> when spi flash use the pin.then nand request the pin it will fail,I just add
> the current(nand) process in an wait queue,after the spi flash pinctl_put,
> spi will wake_up the wait queue.
>
> when nand use the pin,if spi request fail, I add the spi process on the same
> wait queue,when nand release the pin,nand will wake up the wait queue.
> Is that ok?

This sounds like a horribly complicated hack to do something
very simple. Look at the problem from a higher level.

Why do you do this? Obviously you have either NOR or NAND
connected? Don't you know from the system board file or
device tree which one it is?

Yours,
Linus Walleij