[PATCH 0/9] ARM: at91/dt: add missing devices to rm9200ek board

[PATCH 0/9] ARM: at91/dt: add missing devices to rm9200ek board

[Boris BREZILLON]

Hello,

This patch series adds support for the remaining devices (or device options)
not yet supported in dt.

AFAICT there is no more infos/devices not converted to dt for this board,
and we should be able to remove board-at91rm9200ek.c (when we decide to
do it).

This series was not tested (the dt compilation passed), could someone
owning this board test it ?

In order to test it, you need to apply these series first:
https://lkml.org/lkml/2013/8/27/58
pinctrl: at91: add support for OUTPUT config

Best Regards,

Boris

Boris BREZILLON (9):
  ARM: at91/dt: rm9200: add spi0 chip select pins definitions
  ARM: at91/dt: add ethernet phy to at91rm9200ek board
  ARM: at91/dt: add usb1 vbus and pullup pins
  ARM: at91/dt: add atmel,pullup-gpio to at91rm9200ek usb1 definition
  ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board
  ARM: at91/dt: add spi0 support to at91rm9200ek board
  ARM: at91/dt: add i2c devices connected to at91rm9200ek board
  ARM: at91/dt: add new at91rm9200ek_mmc board
  ARM: at91/dt: add new at91rm9200ek_dataflash board

 arch/arm/boot/dts/at91rm9200.dtsi            |   20 ++++++
 arch/arm/boot/dts/at91rm9200ek.dts           |   88 ++++++++++++++++++++++++++
 arch/arm/boot/dts/at91rm9200ek_dataflash.dts |   33 ++++++++++
 arch/arm/boot/dts/at91rm9200ek_mmc.dts       |   23 +++++++
 4 files changed, 164 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91rm9200ek_dataflash.dts
 create mode 100644 arch/arm/boot/dts/at91rm9200ek_mmc.dts

-- 
1.7.9.5

[PATCH 1/9] ARM: at91/dt: add rm9200 spi0 chip select pins definitions

[Boris BREZILLON]

Add spi0 cs pinctrl pins definitions.

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200.dtsi |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
index f770655..69b76c7 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -486,6 +486,26 @@
 							 AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA1 periph A SPI0_MOSI pin */
 							 AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA2 periph A SPI0_SPCK pin */
 					};
+
+					pinctrl_spi0_cs0: spi0_cs0-0 {
+						atmel,pins =
+							<AT91_PIOA 3 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA3 periph A SPI0_NPCS0 pin */
+					};
+
+					pinctrl_spi0_cs1: spi0_cs1-0 {
+						atmel,pins =
+							<AT91_PIOA 4 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA4 GPIO SPI0_NPCS1 pin */
+					};
+
+					pinctrl_spi0_cs2: spi0_cs2-0 {
+						atmel,pins =
+							<AT91_PIOA 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA5 GPIO SPI0_NPCS2 pin */
+					};
+
+					pinctrl_spi0_cs3: spi0_cs3-0 {
+						atmel,pins =
+							<AT91_PIOA 6 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA6 GPIO SPI0_NPCS3 pin */
+					};
 				};
 
 				pioA: gpio at fffff400 {
-- 
1.7.9.5

[PATCH 1/9] ARM: at91/dt: add rm9200 spi0 chip select pins definitions

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:02 Wed 28 Aug     , Boris BREZILLON wrote:
> Add spi0 cs pinctrl pins definitions.
> 
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>  arch/arm/boot/dts/at91rm9200.dtsi |   20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
> index f770655..69b76c7 100644
> --- a/arch/arm/boot/dts/at91rm9200.dtsi
> +++ b/arch/arm/boot/dts/at91rm9200.dtsi
> @@ -486,6 +486,26 @@
>  							 AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA1 periph A SPI0_MOSI pin */
>  							 AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA2 periph A SPI0_SPCK pin */
>  					};
> +
> +					pinctrl_spi0_cs0: spi0_cs0-0 {
> +						atmel,pins =
> +							<AT91_PIOA 3 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA3 periph A SPI0_NPCS0 pin */
> +					};
> +
> +					pinctrl_spi0_cs1: spi0_cs1-0 {
> +						atmel,pins =
> +							<AT91_PIOA 4 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA4 GPIO SPI0_NPCS1 pin */
> +					};
> +
> +					pinctrl_spi0_cs2: spi0_cs2-0 {
> +						atmel,pins =
> +							<AT91_PIOA 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA5 GPIO SPI0_NPCS2 pin */
> +					};
> +
> +					pinctrl_spi0_cs3: spi0_cs3-0 {
> +						atmel,pins =
> +							<AT91_PIOA 6 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA6 GPIO SPI0_NPCS3 pin */
> +					};
nack the pin are not multidrive there is only one master

Best Regards,
J.
>  				};
>  
>  				pioA: gpio at fffff400 {
> -- 
> 1.7.9.5
> 

[PATCH 1/9] ARM: at91/dt: add rm9200 spi0 chip select pins definitions

[boris brezillon]

On 20/11/2013 15:56, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:02 Wed 28 Aug     , Boris BREZILLON wrote:
>> Add spi0 cs pinctrl pins definitions.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>>   arch/arm/boot/dts/at91rm9200.dtsi |   20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/at91rm9200.dtsi b/arch/arm/boot/dts/at91rm9200.dtsi
>> index f770655..69b76c7 100644
>> --- a/arch/arm/boot/dts/at91rm9200.dtsi
>> +++ b/arch/arm/boot/dts/at91rm9200.dtsi
>> @@ -486,6 +486,26 @@
>>   							 AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE	/* PA1 periph A SPI0_MOSI pin */
>>   							 AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA2 periph A SPI0_SPCK pin */
>>   					};
>> +
>> +					pinctrl_spi0_cs0: spi0_cs0-0 {
>> +						atmel,pins =
>> +							<AT91_PIOA 3 AT91_PERIPH_A AT91_PINCTRL_NONE>;	/* PA3 periph A SPI0_NPCS0 pin */
>> +					};
>> +
>> +					pinctrl_spi0_cs1: spi0_cs1-0 {
>> +						atmel,pins =
>> +							<AT91_PIOA 4 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA4 GPIO SPI0_NPCS1 pin */
>> +					};
>> +
>> +					pinctrl_spi0_cs2: spi0_cs2-0 {
>> +						atmel,pins =
>> +							<AT91_PIOA 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA5 GPIO SPI0_NPCS2 pin */
>> +					};
>> +
>> +					pinctrl_spi0_cs3: spi0_cs3-0 {
>> +						atmel,pins =
>> +							<AT91_PIOA 6 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;	/* PA6 GPIO SPI0_NPCS3 pin */
>> +					};
> nack the pin are not multidrive there is only one master
Right, this is a mistake.

But the pins should be configured as OUTPUT with HIGH level
(see 
http://lxr.free-electrons.com/source/arch/arm/mach-at91/at91rm9200_devices.c#L589).

>
> Best Regards,
> J.
>>   				};
>>   
>>   				pioA: gpio at fffff400 {
>> -- 
>> 1.7.9.5
>>

[PATCH 1/9] ARM: at91/dt: add rm9200 spi0 chip select pins definitions

[boris brezillon]

On 20/11/2013 16:59, boris brezillon wrote:
> On 20/11/2013 15:56, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 13:02 Wed 28 Aug     , Boris BREZILLON wrote:
>>> Add spi0 cs pinctrl pins definitions.
>>>
>>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>>> ---
>>>   arch/arm/boot/dts/at91rm9200.dtsi |   20 ++++++++++++++++++++
>>>   1 file changed, 20 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
>>> b/arch/arm/boot/dts/at91rm9200.dtsi
>>> index f770655..69b76c7 100644
>>> --- a/arch/arm/boot/dts/at91rm9200.dtsi
>>> +++ b/arch/arm/boot/dts/at91rm9200.dtsi
>>> @@ -486,6 +486,26 @@
>>>                                AT91_PIOA 1 AT91_PERIPH_A
>>> AT91_PINCTRL_NONE    /* PA1 periph A SPI0_MOSI pin */
>>>                                AT91_PIOA 2 AT91_PERIPH_A
>>> AT91_PINCTRL_NONE>;    /* PA2 periph A SPI0_SPCK pin */
>>>                       };
>>> +
>>> +                    pinctrl_spi0_cs0: spi0_cs0-0 {
>>> +                        atmel,pins =
>>> +                            <AT91_PIOA 3 AT91_PERIPH_A
>>> AT91_PINCTRL_NONE>;    /* PA3 periph A SPI0_NPCS0 pin */
>>> +                    };
>>> +
>>> +                    pinctrl_spi0_cs1: spi0_cs1-0 {
>>> +                        atmel,pins =
>>> +                            <AT91_PIOA 4 AT91_PERIPH_GPIO
>>> AT91_PINCTRL_MULTI_DRIVE>;    /* PA4 GPIO SPI0_NPCS1 pin */
>>> +                    };
>>> +
>>> +                    pinctrl_spi0_cs2: spi0_cs2-0 {
>>> +                        atmel,pins =
>>> +                            <AT91_PIOA 5 AT91_PERIPH_GPIO
>>> AT91_PINCTRL_MULTI_DRIVE>;    /* PA5 GPIO SPI0_NPCS2 pin */
>>> +                    };
>>> +
>>> +                    pinctrl_spi0_cs3: spi0_cs3-0 {
>>> +                        atmel,pins =
>>> +                            <AT91_PIOA 6 AT91_PERIPH_GPIO
>>> AT91_PINCTRL_MULTI_DRIVE>;    /* PA6 GPIO SPI0_NPCS3 pin */
>>> +                    };
>> nack the pin are not multidrive there is only one master
> Right, this is a mistake.
>
> But the pins should be configured as OUTPUT with HIGH level
> (see
> http://lxr.free-electrons.com/source/arch/arm/mach-at91/at91rm9200_devices.c#L589).
>

Okay, my mistake again, declaring "cs-gpios" property should suffice 
(the atmel spi driver will configure it accordingly when probing the spi 
device).

>
>>
>> Best Regards,
>> J.
>>>                   };
>>>                   pioA: gpio at fffff400 {
>>> --
>>> 1.7.9.5
>>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/9] ARM: at91/dt: add ethernet phy to at91rm9200ek board

[Boris BREZILLON]

Add ethernet phy node in at91rm9200ek.dts.
The reg register is not specified, as it may differ depending on the init
process of the board:
ADDR0/1 phy pins are connected to PA13/14 rm9200 pins. Which means the phy
will take its address from these pins during the reset process.

The macb driver will launch a full scan on the mdio bus to discover the phy
address.

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek.dts |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index d2d72c3..37b0880 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -47,6 +47,11 @@
 			macb0: ethernet at fffbc000 {
 				phy-mode = "rmii";
 				status = "okay";
+
+				phy0: ethernet-phy {
+					interrupt-parent = <&pioC>;
+					interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+				};
 			};
 
 			usb1: gadget at fffb0000 {
-- 
1.7.9.5

[PATCH 2/9] ARM: at91/dt: add ethernet phy to at91rm9200ek board

[boris brezillon]

On 28/08/2013 13:03, Boris BREZILLON wrote:
> Add ethernet phy node in at91rm9200ek.dts.
> The reg register is not specified, as it may differ depending on the init
> process of the board:
> ADDR0/1 phy pins are connected to PA13/14 rm9200 pins. Which means the phy
> will take its address from these pins during the reset process.
>
> The macb driver will launch a full scan on the mdio bus to discover the phy
> address.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>   arch/arm/boot/dts/at91rm9200ek.dts |    5 +++++
>   1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
> index d2d72c3..37b0880 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -47,6 +47,11 @@
>   			macb0: ethernet at fffbc000 {
>   				phy-mode = "rmii";
>   				status = "okay";
> +
> +				phy0: ethernet-phy {
> +					interrupt-parent = <&pioC>;
> +					interrupts = <4 IRQ_TYPE_EDGE_FALLING>;

rm9200 pio controller does not support specific edge detection.
The line above should be replaced with:
				interrupts = <4 IRQ_TYPE_EDGE_BOTH>;
or
				interrupts = <4 0>;

Nicolas, I know you were planning to push this patch for 3.14.
If you haven't done it yet (or if you changed your mind), I can send a 
new version including this fix.


> +				};
>   			};
>
>   			usb1: gadget at fffb0000 {
>

[PATCH 3/9] ARM: at91/dt: add usb1 vbus and pullup pins

[Boris BREZILLON]

Add vbus and pullup pinctrl definitions.
Request the vbus and pullup pins in usb1 node.

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek.dts |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index 37b0880..76f3e87 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -29,6 +29,18 @@
 
 	ahb {
 		apb {
+			pinctrl at fffff400 {
+				usb1 {
+					pinctrl_usb1_vbus: usb1_vbus-0 {
+						atmel,pins = <AT91_PIOD 4 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
+					};
+
+					pinctrl_usb1_pullup: usb1_pullup-0 {
+						atmel,pins = <AT91_PIOD 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
+					};
+				};
+			};
+
 			dbgu: serial at fffff200 {
 				status = "okay";
 			};
@@ -56,6 +68,9 @@
 
 			usb1: gadget at fffb0000 {
 				atmel,vbus-gpio = <&pioD 4 GPIO_ACTIVE_HIGH>;
+				pinctrl-names = "default";
+				pinctrl-0 = <&pinctrl_usb1_vbus
+					     &pinctrl_usb1_pullup>;
 				status = "okay";
 			};
 
-- 
1.7.9.5

[PATCH 3/9] ARM: at91/dt: add usb1 vbus and pullup pins

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:04 Wed 28 Aug     , Boris BREZILLON wrote:
> Add vbus and pullup pinctrl definitions.
> Request the vbus and pullup pins in usb1 node.
> 
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>  arch/arm/boot/dts/at91rm9200ek.dts |   15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
> index 37b0880..76f3e87 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -29,6 +29,18 @@
>  
>  	ahb {
>  		apb {
> +			pinctrl at fffff400 {
> +				usb1 {
> +					pinctrl_usb1_vbus: usb1_vbus-0 {
> +						atmel,pins = <AT91_PIOD 4 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
> +					};

it's a gpio no-need
> +
> +					pinctrl_usb1_pullup: usb1_pullup-0 {
> +						atmel,pins = <AT91_PIOD 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
> +					};
no-need multidrive
> +				};
> +			};
> +
>  			dbgu: serial at fffff200 {
>  				status = "okay";
>  			};
> @@ -56,6 +68,9 @@
>  
>  			usb1: gadget at fffb0000 {
>  				atmel,vbus-gpio = <&pioD 4 GPIO_ACTIVE_HIGH>;
> +				pinctrl-names = "default";
> +				pinctrl-0 = <&pinctrl_usb1_vbus
> +					     &pinctrl_usb1_pullup>;
>  				status = "okay";
>  			};
>  
> -- 
> 1.7.9.5
> 

[PATCH 3/9] ARM: at91/dt: add usb1 vbus and pullup pins

[boris brezillon]

On 20/11/2013 15:57, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:04 Wed 28 Aug     , Boris BREZILLON wrote:
>> Add vbus and pullup pinctrl definitions.
>> Request the vbus and pullup pins in usb1 node.
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>>   arch/arm/boot/dts/at91rm9200ek.dts |   15 +++++++++++++++
>>   1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
>> index 37b0880..76f3e87 100644
>> --- a/arch/arm/boot/dts/at91rm9200ek.dts
>> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
>> @@ -29,6 +29,18 @@
>>   
>>   	ahb {
>>   		apb {
>> +			pinctrl at fffff400 {
>> +				usb1 {
>> +					pinctrl_usb1_vbus: usb1_vbus-0 {
>> +						atmel,pins = <AT91_PIOD 4 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>;
>> +					};
> it's a gpio no-need

Okay, noted.

I thought I had to declare gpio configured pins in order to detect pin 
conflicts.
But after taking a closer look at the pinctrl core and at91 pinctrl 
driver, it seems this is automatically done
by means of the pinctrl_request_gpio function.


>> +
>> +					pinctrl_usb1_pullup: usb1_pullup-0 {
>> +						atmel,pins = <AT91_PIOD 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
>> +					};
> no-need multidrive

Then why is it configured with multi-drive option in the board file
( 
http://lxr.free-electrons.com/source/arch/arm/mach-at91/board-rm9200ek.c#L166) 
?

>> +				};
>> +			};
>> +
>>   			dbgu: serial at fffff200 {
>>   				status = "okay";
>>   			};
>> @@ -56,6 +68,9 @@
>>   
>>   			usb1: gadget at fffb0000 {
>>   				atmel,vbus-gpio = <&pioD 4 GPIO_ACTIVE_HIGH>;
>> +				pinctrl-names = "default";
>> +				pinctrl-0 = <&pinctrl_usb1_vbus
>> +					     &pinctrl_usb1_pullup>;
>>   				status = "okay";
>>   			};
>>   
>> -- 
>> 1.7.9.5
>>

[PATCH 4/9] ARM: at91/dt: add atmel, pullup-gpio to at91rm9200ek usb1 definition

[Boris BREZILLON]

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek.dts |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index 76f3e87..f2d6d79 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -68,6 +68,7 @@
 
 			usb1: gadget at fffb0000 {
 				atmel,vbus-gpio = <&pioD 4 GPIO_ACTIVE_HIGH>;
+				atmel,pullup-gpio = <&pioD 5 GPIO_ACTIVE_HIGH>;
 				pinctrl-names = "default";
 				pinctrl-0 = <&pinctrl_usb1_vbus
 					     &pinctrl_usb1_pullup>;
-- 
1.7.9.5

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Boris BREZILLON]

Add slot0 of mmc0 pinctrl pins definitions:
 - detect pin
 - write protect pin
 - enable slot0 pin: this pin is connected to an external switch which
   enable mmc0 slot0 or spi dataflash connected to cs3

The mmc0 device is not enabled, as it depends on the choosen functionnality
(spi cs3 or mmc0 slot0).

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek.dts |   35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index f2d6d79..2bad423 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -39,6 +39,23 @@
 						atmel,pins = <AT91_PIOD 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
 					};
 				};
+
+				mmc0 {
+					pinctrl_mmc0_slot0_detect: mmc0_slot0_detect-0 {
+						atmel,pins =
+							<AT91_PIOB 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
+					};
+
+					pinctrl_mmc0_slot0_write_protect: mmc0_slot0_write_protect-0 {
+						atmel,pins =
+							<AT91_PIOA 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+					};
+
+					pinctrl_mmc0_slot0_switch: mmc0_slot0_switch-0 {
+						atmel,pins =
+							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
+					};
+				};
 			};
 
 			dbgu: serial at fffff200 {
@@ -84,6 +101,24 @@
 					reg = <0>;
 				};
 			};
+
+			mmc0: mmc at fffb4000 {
+				#address-cells = <1>;
+				#size-cells = <0>;
+				pinctrl-0 = <&pinctrl_mmc0_clk
+					     &pinctrl_mmc0_slot0_cmd_dat0
+					     &pinctrl_mmc0_slot0_dat1_3
+					     &pinctrl_mmc0_slot0_detect
+					     &pinctrl_mmc0_slot0_write_protect
+					     &pinctrl_mmc0_slot0_switch>;
+
+				slot0: slot at 0 {
+					reg = <0>;
+					bus-width = <4>;
+					cd-gpios = <&pioB 27 GPIO_ACTIVE_HIGH>;
+					wp-gpios = <&pioA 17 GPIO_ACTIVE_HIGH>;
+				};
+			};
 		};
 
 		usb0: ohci at 00300000 {
-- 
1.7.9.5

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:06 Wed 28 Aug     , Boris BREZILLON wrote:
> Add slot0 of mmc0 pinctrl pins definitions:
>  - detect pin
>  - write protect pin
>  - enable slot0 pin: this pin is connected to an external switch which
>    enable mmc0 slot0 or spi dataflash connected to cs3
> 
> The mmc0 device is not enabled, as it depends on the choosen functionnality
> (spi cs3 or mmc0 slot0).
> 
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>  arch/arm/boot/dts/at91rm9200ek.dts |   35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
> index f2d6d79..2bad423 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -39,6 +39,23 @@
>  						atmel,pins = <AT91_PIOD 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
>  					};
>  				};
> +
> +				mmc0 {
> +					pinctrl_mmc0_slot0_detect: mmc0_slot0_detect-0 {
> +						atmel,pins =
> +							<AT91_PIOB 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> +					};
> +
> +					pinctrl_mmc0_slot0_write_protect: mmc0_slot0_write_protect-0 {
> +						atmel,pins =
> +							<AT91_PIOA 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> +					};
> +
> +					pinctrl_mmc0_slot0_switch: mmc0_slot0_switch-0 {
> +						atmel,pins =
> +							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
> +					};
nack this is a regulator the pinctrl API is not done for gpio default value
> +				};
>  			};
>  
>  			dbgu: serial at fffff200 {
> @@ -84,6 +101,24 @@
>  					reg = <0>;
>  				};
>  			};
> +
> +			mmc0: mmc at fffb4000 {
> +				#address-cells = <1>;
> +				#size-cells = <0>;
> +				pinctrl-0 = <&pinctrl_mmc0_clk
> +					     &pinctrl_mmc0_slot0_cmd_dat0
> +					     &pinctrl_mmc0_slot0_dat1_3
> +					     &pinctrl_mmc0_slot0_detect
> +					     &pinctrl_mmc0_slot0_write_protect
> +					     &pinctrl_mmc0_slot0_switch>;
> +
> +				slot0: slot at 0 {
> +					reg = <0>;
> +					bus-width = <4>;
> +					cd-gpios = <&pioB 27 GPIO_ACTIVE_HIGH>;
> +					wp-gpios = <&pioA 17 GPIO_ACTIVE_HIGH>;
> +				};
> +			};
>  		};
>  
>  		usb0: ohci at 00300000 {
> -- 
> 1.7.9.5
> 

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[boris brezillon]

On 20/11/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:06 Wed 28 Aug     , Boris BREZILLON wrote:
>> Add slot0 of mmc0 pinctrl pins definitions:
>>   - detect pin
>>   - write protect pin
>>   - enable slot0 pin: this pin is connected to an external switch which
>>     enable mmc0 slot0 or spi dataflash connected to cs3
>>
>> The mmc0 device is not enabled, as it depends on the choosen functionnality
>> (spi cs3 or mmc0 slot0).
>>
>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>>   arch/arm/boot/dts/at91rm9200ek.dts |   35 +++++++++++++++++++++++++++++++++++
>>   1 file changed, 35 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
>> index f2d6d79..2bad423 100644
>> --- a/arch/arm/boot/dts/at91rm9200ek.dts
>> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
>> @@ -39,6 +39,23 @@
>>   						atmel,pins = <AT91_PIOD 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
>>   					};
>>   				};
>> +
>> +				mmc0 {
>> +					pinctrl_mmc0_slot0_detect: mmc0_slot0_detect-0 {
>> +						atmel,pins =
>> +							<AT91_PIOB 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
>> +					};
>> +
>> +					pinctrl_mmc0_slot0_write_protect: mmc0_slot0_write_protect-0 {
>> +						atmel,pins =
>> +							<AT91_PIOA 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
>> +					};
>> +
>> +					pinctrl_mmc0_slot0_switch: mmc0_slot0_switch-0 {
>> +						atmel,pins =
>> +							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
>> +					};
> nack this is a regulator the pinctrl API is not done for gpio default value

I know this can be represented as a regulator, but looking at the 
datasheet, this looks more
like a switch than a regulator.

Anyway, why didn't you told me that when I proposed the OUTPUT support 
for at91 pinctrl driver ?
And BTW pinctrl OUTPUT config is already supported by some pinctrl drivers
( 
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt#L159).

>> +				};
>>   			};
>>   
>>   			dbgu: serial at fffff200 {
>> @@ -84,6 +101,24 @@
>>   					reg = <0>;
>>   				};
>>   			};
>> +
>> +			mmc0: mmc at fffb4000 {
>> +				#address-cells = <1>;
>> +				#size-cells = <0>;
>> +				pinctrl-0 = <&pinctrl_mmc0_clk
>> +					     &pinctrl_mmc0_slot0_cmd_dat0
>> +					     &pinctrl_mmc0_slot0_dat1_3
>> +					     &pinctrl_mmc0_slot0_detect
>> +					     &pinctrl_mmc0_slot0_write_protect
>> +					     &pinctrl_mmc0_slot0_switch>;
>> +
>> +				slot0: slot at 0 {
>> +					reg = <0>;
>> +					bus-width = <4>;
>> +					cd-gpios = <&pioB 27 GPIO_ACTIVE_HIGH>;
>> +					wp-gpios = <&pioA 17 GPIO_ACTIVE_HIGH>;
>> +				};
>> +			};
>>   		};
>>   
>>   		usb0: ohci at 00300000 {
>> -- 
>> 1.7.9.5
>>

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:14 Wed 20 Nov     , boris brezillon wrote:
> On 20/11/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 13:06 Wed 28 Aug     , Boris BREZILLON wrote:
> >>Add slot0 of mmc0 pinctrl pins definitions:
> >>  - detect pin
> >>  - write protect pin
> >>  - enable slot0 pin: this pin is connected to an external switch which
> >>    enable mmc0 slot0 or spi dataflash connected to cs3
> >>
> >>The mmc0 device is not enabled, as it depends on the choosen functionnality
> >>(spi cs3 or mmc0 slot0).
> >>
> >>Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> >>---
> >>  arch/arm/boot/dts/at91rm9200ek.dts |   35 +++++++++++++++++++++++++++++++++++
> >>  1 file changed, 35 insertions(+)
> >>
> >>diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
> >>index f2d6d79..2bad423 100644
> >>--- a/arch/arm/boot/dts/at91rm9200ek.dts
> >>+++ b/arch/arm/boot/dts/at91rm9200ek.dts
> >>@@ -39,6 +39,23 @@
> >>  						atmel,pins = <AT91_PIOD 5 AT91_PERIPH_GPIO AT91_PINCTRL_MULTI_DRIVE>;
> >>  					};
> >>  				};
> >>+
> >>+				mmc0 {
> >>+					pinctrl_mmc0_slot0_detect: mmc0_slot0_detect-0 {
> >>+						atmel,pins =
> >>+							<AT91_PIOB 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>;
> >>+					};
> >>+
> >>+					pinctrl_mmc0_slot0_write_protect: mmc0_slot0_write_protect-0 {
> >>+						atmel,pins =
> >>+							<AT91_PIOA 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
> >>+					};
> >>+
> >>+					pinctrl_mmc0_slot0_switch: mmc0_slot0_switch-0 {
> >>+						atmel,pins =
> >>+							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
> >>+					};
> >nack this is a regulator the pinctrl API is not done for gpio default value
> 
> I know this can be represented as a regulator, but looking at the
> datasheet, this looks more
> like a switch than a regulator.

so you load the dt via user space and use the regulator NOT the pinctrl

I do not want to see gpio control via pinctrl as we have no tracability of it
in gpio lib what so ever

> 
> Anyway, why didn't you told me that when I proposed the OUTPUT
> support for at91 pinctrl driver ?

you never get my Ack for this and I'm the pinctrl-at91 maintainer

so NACK

Best Regards,
J.

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Linus Walleij]

On Wed, Nov 20, 2013 at 5:14 PM, boris brezillon
<b.brezillon@overkiz.com> wrote:
> On 20/11/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 13:06 Wed 28 Aug     , Boris BREZILLON wrote:

>>> mmc0_slot0_switch-0 {
>>> +                                               atmel,pins =
>>> +                                                       <AT91_PIOB 22
>>> AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
>>> +                                       };
>>
>> nack this is a regulator the pinctrl API is not done for gpio default
>> value
>
> I know this can be represented as a regulator, but looking at the datasheet,
> this looks more like a switch than a regulator.

No matter whether it's a switch or a GPIO regulator it seems we
are in violent agreement that it should not be controlled by the
pin control states at least.

Start with making it a GPIO then you can figure out whether
a GPIO regulator or drivers/extcon/extcon-gpio.c should be
used.

Yours,
Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[boris brezillon]

Hi Linus,

On 21/11/2013 10:48, Linus Walleij wrote:
> On Wed, Nov 20, 2013 at 5:14 PM, boris brezillon
> <b.brezillon@overkiz.com> wrote:
>> On 20/11/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 13:06 Wed 28 Aug     , Boris BREZILLON wrote:
>>>> mmc0_slot0_switch-0 {
>>>> +                                               atmel,pins =
>>>> +                                                       <AT91_PIOB 22
>>>> AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
>>>> +                                       };
>>> nack this is a regulator the pinctrl API is not done for gpio default
>>> value
>> I know this can be represented as a regulator, but looking at the datasheet,
>> this looks more like a switch than a regulator.
> No matter whether it's a switch or a GPIO regulator it seems we
> are in violent agreement that it should not be controlled by the
> pin control states at least.
>
> Start with making it a GPIO then you can figure out whether
> a GPIO regulator or drivers/extcon/extcon-gpio.c should be
> used.

Thanks for pointing this out. I wasn't aware of the extcon subsystem.

Actually, I think it's a little bit more tricky.

The switch connected to gpio PB22 is used to enable one device or the other:
  - PB22 set to high level enables slot0 of mmc0 (connect mmc signals to 
the mmc
    connector)
  - PB22 set to low level enables the dataflash (connect to the SPI0 
signals to the
    dataflash device)

I can declare a regulator for the mmc device and attach it to the mmc 
(AFAIK, the
mmc core will request the mmc regulator for us, and configure it 
accordingly).

But AFAICT (tell me if I'm wrong), there's no such things for spi devices.

The pinctrl approach has the benefit of providing a transparent way (no 
existing
drivers modifications) to enable one device or the other.

But if you think this is better done (or cleaner) with an extcon or a 
regulator device,
I'll try to find a way to do it this way.

Best Regards,

Boris

>
> Yours,
> Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Linus Walleij]

On Thu, Nov 21, 2013 at 11:34 AM, boris brezillon
<b.brezillon@overkiz.com> wrote:
> On 21/11/2013 10:48, Linus Walleij wrote:

>> No matter whether it's a switch or a GPIO regulator it seems we
>> are in violent agreement that it should not be controlled by the
>> pin control states at least.
>>
>> Start with making it a GPIO then you can figure out whether
>> a GPIO regulator or drivers/extcon/extcon-gpio.c should be
>> used.
>
> Thanks for pointing this out. I wasn't aware of the extcon subsystem.
>
> Actually, I think it's a little bit more tricky.

Hm, yeah extcon is for things like audio jacks on phones that
userspace need to detect.

drivers/input/keyboard/gpio_keys* is for things that actually
input characters to userspace stuff.

None of it is applicable here it seems ...

> The switch connected to gpio PB22 is used to enable one device or the other:
>  - PB22 set to high level enables slot0 of mmc0 (connect mmc signals to the
> mmc
>    connector)
>  - PB22 set to low level enables the dataflash (connect to the SPI0 signals
> to the
>    dataflash device)

So this is something like a "jumper" of the old type, configuring
the entire system?

Something like that:
http://www.mignonette-game.com/images/v2/21-arduino-com-jumper.jpg

But in this case it is a mechanical switch rather than a jumper?

This is not much different from the GPIOs people use to e.g. encode
the board type, just that it can change.

Do people switch this thing at runtime?

> The pinctrl approach has the benefit of providing a transparent way (no
> existing
> drivers modifications) to enable one device or the other.
>
> But if you think this is better done (or cleaner) with an extcon or a
> regulator device,
> I'll try to find a way to do it this way.

I'm uncertain. If this is something that changes at runtime, the
input from the switch should be read through GPIO and used
to select the "default" state of one device and something like
"sleep" on the other (I suspect more things than pin control
may be affected by that!)

If this is a switch that you want to take the simple shortcut
of just reading at boot, the approach would still be similar, just
less code.

So use gpio_get() to read the value, and then select which
*entire device* goes active depending on the setting would
be the right approach I guess?

Yours,
Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[boris brezillon]

Hello Linus,

Sorry for the noise, my mail was filtered by several ML because of some 
HTML contents.

Le 26/11/2013 14:46, Linus Walleij a ?crit :
> On Thu, Nov 21, 2013 at 11:34 AM, boris brezillon
> <b.brezillon@overkiz.com>  wrote:
>> On 21/11/2013 10:48, Linus Walleij wrote:
>>> No matter whether it's a switch or a GPIO regulator it seems we
>>> are in violent agreement that it should not be controlled by the
>>> pin control states at least.
>>>
>>> Start with making it a GPIO then you can figure out whether
>>> a GPIO regulator or drivers/extcon/extcon-gpio.c should be
>>> used.
>> Thanks for pointing this out. I wasn't aware of the extcon subsystem.
>>
>> Actually, I think it's a little bit more tricky.
> Hm, yeah extcon is for things like audio jacks on phones that
> userspace need to detect.
>
> drivers/input/keyboard/gpio_keys* is for things that actually
> input characters to userspace stuff.
>
> None of it is applicable here it seems ...
>
>> The switch connected to gpio PB22 is used to enable one device or the other:
>>   - PB22 set to high level enables slot0 of mmc0 (connect mmc signals to the
>> mmc
>>     connector)
>>   - PB22 set to low level enables the dataflash (connect to the SPI0 signals
>> to the
>>     dataflash device)
> So this is something like a "jumper" of the old type, configuring
> the entire system?
>
> Something like that:
> http://www.mignonette-game.com/images/v2/21-arduino-com-jumper.jpg
>
> But in this case it is a mechanical switch rather than a jumper?
Not exactly.
The functionnaly selection (spi device or mmc slot) is done by the 
software using to the
PB22 pin:
  - set PB22 pin to 1 if you want to enable the mmc slot
  - set PB22 pin to 0 if you want to enable the spi device

This is the rm9200ek board datasheet 
http://www.alliedelec.com/images/products/datasheets/bm/ATMEL/70123901.pdf, 
and you'll find the switch schematic at page 26.
Here is the switch datasheet : 
http://pdf1.alldatasheet.fr/datasheet-pdf/view/90971/PERICOM/PI5A100Q.html

If I understand correctly, you're suggesting to retrieve the PB22 pin 
value to decide
wether the mmc slot or the spi device is enabled. Is that right ?

In this case the bootstrap and/or bootloader would have to properly 
configure the P22 pin
before executing the linux kernel, and I'm pretty sure this is not the case.

> This is not much different from the GPIOs people use to e.g. encode
> the board type, just that it can change.
>
> Do people switch this thing at runtime?

In the board version this was configured in the init_machine function 
(or board init
function) depending on the MTD_AT91_DATAFLASH_CARD
( 
http://lxr.free-electrons.com/source/arch/arm/mach-at91/board-rm9200ek.c#L173).
As a result it was not reconfigurable at runtime.

But Jean-Christophe suggested to make it configurable at runtime (using 
dt fragments).

>> The pinctrl approach has the benefit of providing a transparent way (no
>> existing
>> drivers modifications) to enable one device or the other.
>>
>> But if you think this is better done (or cleaner) with an extcon or a
>> regulator device,
>> I'll try to find a way to do it this way.
> I'm uncertain. If this is something that changes at runtime, the
> input from the switch should be read through GPIO and used
> to select the "default" state of one device and something like
> "sleep" on the other (I suspect more things than pin control
> may be affected by that!)
>
> If this is a switch that you want to take the simple shortcut
> of just reading at boot, the approach would still be similar, just
> less code.
>
> So use gpio_get() to read the value, and then select which
> *entire device* goes active depending on the setting would
> be the right approach I guess?

I'm not sure these suggestions apply according to my previous answers,
but tell me if I'm wrong.

Thanks for your time and suggestions.

Best Regards,

Boris

> Yours,
> Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Linus Walleij]

P? tisdag, 26 Nov, 2013 vid 6:11 PM, skrev boris brezillon
<b.brezillon@overkiz.com>:
> Le 26/11/2013 14:46, Linus Walleij a ?crit :

>> But in this case it is a mechanical switch rather than a jumper?
>
> Not exactly.
>
> The functionnaly selection (spi device or mmc slot) is done by the software
> using to the
> PB22 pin:
>  - set PB22 pin to 1 if you want to enable the mmc slot
>  - set PB22 pin to 0 if you want to enable the spi device

OK I got it wrong, I thought it was a mechanical switch. So this is a GPIO
line somekindof, you control it like this, and it will have effects on the
electronics.

So to get the device running you need to both:

- Switch the value of this GPIO line.
- Switch pin control state.

We are certain that the gpio_set_value() shall be used to set that GPIO
line, because it does not control any pin control logic, it controls
some electronics outside of the SoC, and that is outside the pin
controller domain.

I guess one way is to obtain this GPIO in board code and just
flick it depending on which device you register.

You can have GPIOs tied to the machine/board itself, see this
fragment from arch/arm/boot/dts/ste-nomadik-s8815.dts:

        /* Custom board node with GPIO pins to active etc */
        usb-s8815 {
                /* This will bias the MMC/SD card detect line */
                mmcsd-gpio {
                        gpios = <&gpio3 16 0x1>;
                };
        };

This GPIO needs to be driven high to bias the MMC/SD card.
I solved it like this in the board code in
arch/arm/mach-nomadik/cpu-8815.c:

/*
 * This GPIO pin turns on a line that is used to detect card insertion
 * on this board.
 */
static int __init cpu8815_mmcsd_init(void)
{
        struct device_node *cdbias;
        int gpio, err;

        cdbias = of_find_node_by_path("/usb-s8815/mmcsd-gpio");
        if (!cdbias) {
                pr_info("could not find MMC/SD card detect bias node\n");
                return 0;
        }
        gpio = of_get_gpio(cdbias, 0);
        if (gpio < 0) {
                pr_info("could not obtain MMC/SD card detect bias GPIO\n");
                return 0;
        }
        err = gpio_request(gpio, "card detect bias");
        if (err) {
                pr_info("failed to request card detect bias GPIO %d\n", gpio);
                return -ENODEV;
        }
        err = gpio_direction_output(gpio, 0);
        if (err){
                pr_info("failed to set GPIO %d as output, low\n", gpio);
                return err;
        }
        pr_info("enabled USB-S8815 CD bias GPIO %d, low\n", gpio);
        return 0;
}
device_initcall(cpu8815_mmcsd_init);

This is maybe not a perfect approach :-/

But you get the idea. You could set this up one way or another
depending on whether this board is registering a device for
SPI or MMC.

Probably Jean-Christophe has opinions on this so let's see what
he says.

> If I understand correctly, you're suggesting to retrieve the PB22 pin value
> to decide
> wether the mmc slot or the spi device is enabled. Is that right ?

Forget about this, I didn't understand the real problem.

> In the board version this was configured in the init_machine function (or
> board init
> function) depending on the MTD_AT91_DATAFLASH_CARD
> (
> http://lxr.free-electrons.com/source/arch/arm/mach-at91/board-rm9200ek.c#L173).
> As a result it was not reconfigurable at runtime.
>
> But Jean-Christophe suggested to make it configurable at runtime (using dt
> fragments).

It should definately be set up at runtime, just a matter where and
how.

Yours,
Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[boris brezillon]

Hello Linus,

On 29/11/2013 11:03, Linus Walleij wrote:
> P? tisdag, 26 Nov, 2013 vid 6:11 PM, skrev boris brezillon
> <b.brezillon@overkiz.com>:
>> Le 26/11/2013 14:46, Linus Walleij a ?crit :
>>> But in this case it is a mechanical switch rather than a jumper?
>> Not exactly.
>>
>> The functionnaly selection (spi device or mmc slot) is done by the software
>> using to the
>> PB22 pin:
>>   - set PB22 pin to 1 if you want to enable the mmc slot
>>   - set PB22 pin to 0 if you want to enable the spi device
> OK I got it wrong, I thought it was a mechanical switch. So this is a GPIO
> line somekindof, you control it like this, and it will have effects on the
> electronics.
>
> So to get the device running you need to both:
>
> - Switch the value of this GPIO line.
> - Switch pin control state.
>
> We are certain that the gpio_set_value() shall be used to set that GPIO
> line, because it does not control any pin control logic, it controls
> some electronics outside of the SoC, and that is outside the pin
> controller domain.
>
> I guess one way is to obtain this GPIO in board code and just
> flick it depending on which device you register.
>
> You can have GPIOs tied to the machine/board itself, see this
> fragment from arch/arm/boot/dts/ste-nomadik-s8815.dts:
>
>          /* Custom board node with GPIO pins to active etc */
>          usb-s8815 {
>                  /* This will bias the MMC/SD card detect line */
>                  mmcsd-gpio {
>                          gpios = <&gpio3 16 0x1>;
>                  };
>          };
>
> This GPIO needs to be driven high to bias the MMC/SD card.
> I solved it like this in the board code in
> arch/arm/mach-nomadik/cpu-8815.c:
>
> /*
>   * This GPIO pin turns on a line that is used to detect card insertion
>   * on this board.
>   */
> static int __init cpu8815_mmcsd_init(void)
> {
>          struct device_node *cdbias;
>          int gpio, err;
>
>          cdbias = of_find_node_by_path("/usb-s8815/mmcsd-gpio");
>          if (!cdbias) {
>                  pr_info("could not find MMC/SD card detect bias node\n");
>                  return 0;
>          }
>          gpio = of_get_gpio(cdbias, 0);
>          if (gpio < 0) {
>                  pr_info("could not obtain MMC/SD card detect bias GPIO\n");
>                  return 0;
>          }
>          err = gpio_request(gpio, "card detect bias");
>          if (err) {
>                  pr_info("failed to request card detect bias GPIO %d\n", gpio);
>                  return -ENODEV;
>          }
>          err = gpio_direction_output(gpio, 0);
>          if (err){
>                  pr_info("failed to set GPIO %d as output, low\n", gpio);
>                  return err;
>          }
>          pr_info("enabled USB-S8815 CD bias GPIO %d, low\n", gpio);
>          return 0;
> }
> device_initcall(cpu8815_mmcsd_init);
>
> This is maybe not a perfect approach :-/
>
> But you get the idea. You could set this up one way or another
> depending on whether this board is registering a device for
> SPI or MMC.

The whole goal of moving from board files to dt is to drop all board
specific processing or initialization and only keep a common description
with generic drivers capable of handling common use cases.

I'm not sure providing new board specific drivers is a good solution
(even if it is the simplest way to achieve our goal).

Could we have something similar to pinctrl but with gpios :
when the device is probed the device/driver core code request the gpio
configure it appropriately and set it to the requested value (if configured
as output).

Or even better, provide an external switch subsystem (with a gpio-switch 
driver)
and automate switch request/config in device/driver core code (as done 
for the
pinctrl config).

These are just thoughts, and I guess introducing new code in the 
device/driver core
code is not that easy, especially when this code is here to handle 
specific case
like ours.

Thanks for sharing your thoughts.

Best Regards,

Boris

>
> Probably Jean-Christophe has opinions on this so let's see what
> he says.
>
>> If I understand correctly, you're suggesting to retrieve the PB22 pin value
>> to decide
>> wether the mmc slot or the spi device is enabled. Is that right ?
> Forget about this, I didn't understand the real problem.
>
>> In the board version this was configured in the init_machine function (or
>> board init
>> function) depending on the MTD_AT91_DATAFLASH_CARD
>> (
>> http://lxr.free-electrons.com/source/arch/arm/mach-at91/board-rm9200ek.c#L173).
>> As a result it was not reconfigurable at runtime.
>>
>> But Jean-Christophe suggested to make it configurable at runtime (using dt
>> fragments).
> It should definately be set up at runtime, just a matter where and
> how.
>
> Yours,
> Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Linus Walleij]

On Fri, Nov 29, 2013 at 11:30 AM, boris brezillon
<b.brezillon@overkiz.com> wrote:
> On 29/11/2013 11:03, Linus Walleij wrote:

>> I guess one way is to obtain this GPIO in board code and just
>> flick it depending on which device you register.
(...)
> The whole goal of moving from board files to dt is to drop all board
> specific processing or initialization and only keep a common description
> with generic drivers capable of handling common use cases.
>
> I'm not sure providing new board specific drivers is a good solution
> (even if it is the simplest way to achieve our goal).
>
> Could we have something similar to pinctrl but with gpios :
> when the device is probed the device/driver core code request the gpio
> configure it appropriately and set it to the requested value (if configured
> as output).

This has been suggested under the name "GPIO hogs" in the past.

It would work similar to how pinctrl hogs work by associating the
GPIO line the controller itself, using some specific string
like gpio-input-hogs = <...> / gpio-output-hogs = <...>;

The gpiolib core will then grab and set up these before
returning from the registration call so noone ever gets a chance
to use them.

> These are just thoughts, and I guess introducing new code in the
> device/driver core
> code is not that easy, especially when this code is here to handle specific
> case
> like ours.

It is very easy, just write the patch, iterate it (these patches get
a lot of scrutiny as it is core code, so expect some work and time
to get it done), and then unless there is a blocker, I would merge it.
The concept is entirely sound, just that someone needs to step
up and do the work...

Yours,
Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[boris brezillon]

On 29/11/2013 14:31, Linus Walleij wrote:
> On Fri, Nov 29, 2013 at 11:30 AM, boris brezillon
> <b.brezillon@overkiz.com> wrote:
>> On 29/11/2013 11:03, Linus Walleij wrote:
>>> I guess one way is to obtain this GPIO in board code and just
>>> flick it depending on which device you register.
> (...)
>> The whole goal of moving from board files to dt is to drop all board
>> specific processing or initialization and only keep a common description
>> with generic drivers capable of handling common use cases.
>>
>> I'm not sure providing new board specific drivers is a good solution
>> (even if it is the simplest way to achieve our goal).
>>
>> Could we have something similar to pinctrl but with gpios :
>> when the device is probed the device/driver core code request the gpio
>> configure it appropriately and set it to the requested value (if configured
>> as output).
> This has been suggested under the name "GPIO hogs" in the past.
>
> It would work similar to how pinctrl hogs work by associating the
> GPIO line the controller itself, using some specific string
> like gpio-input-hogs = <...> / gpio-output-hogs = <...>;
>
> The gpiolib core will then grab and set up these before
> returning from the registration call so noone ever gets a chance
> to use them.

Ok, I'll take a look.

Could you point me out a thread (or other documents) talking about gpio 
hogs.
I found this one 
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/162254.html.

>> These are just thoughts, and I guess introducing new code in the
>> device/driver core
>> code is not that easy, especially when this code is here to handle specific
>> case
>> like ours.
> It is very easy, just write the patch, iterate it (these patches get
> a lot of scrutiny as it is core code, so expect some work and time
> to get it done), and then unless there is a blocker, I would merge it.
> The concept is entirely sound, just that someone needs to step
> up and do the work...

Sure, I'll propose something (I guess your talking about GPIO hogs 
concept not gpio-switch driver).
If you already thought a bit about GPIO hogs, I'd be interested to get 
some inputs (suggestions, ideas, code, ...).

Anyway, thanks for taking time to answer my questions.

Best Reagrds,

Boris

> Yours,
> Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[boris brezillon]

Hello Linus,

On 29/11/2013 14:31, Linus Walleij wrote:
> On Fri, Nov 29, 2013 at 11:30 AM, boris brezillon
> <b.brezillon@overkiz.com> wrote:
>> On 29/11/2013 11:03, Linus Walleij wrote:
>>> I guess one way is to obtain this GPIO in board code and just
>>> flick it depending on which device you register.
> (...)
>> The whole goal of moving from board files to dt is to drop all board
>> specific processing or initialization and only keep a common description
>> with generic drivers capable of handling common use cases.
>>
>> I'm not sure providing new board specific drivers is a good solution
>> (even if it is the simplest way to achieve our goal).
>>
>> Could we have something similar to pinctrl but with gpios :
>> when the device is probed the device/driver core code request the gpio
>> configure it appropriately and set it to the requested value (if configured
>> as output).
> This has been suggested under the name "GPIO hogs" in the past.
>
> It would work similar to how pinctrl hogs work by associating the
> GPIO line the controller itself, using some specific string
> like gpio-input-hogs = <...> / gpio-output-hogs = <...>;
>
> The gpiolib core will then grab and set up these before
> returning from the registration call so noone ever gets a chance
> to use them.
One more question, and I'm done :).

In which case should we use output-high or output-low config
instead of gpio-output-hogs ?


Best Regards,

Boris
>> These are just thoughts, and I guess introducing new code in the
>> device/driver core
>> code is not that easy, especially when this code is here to handle specific
>> case
>> like ours.
> It is very easy, just write the patch, iterate it (these patches get
> a lot of scrutiny as it is core code, so expect some work and time
> to get it done), and then unless there is a blocker, I would merge it.
> The concept is entirely sound, just that someone needs to step
> up and do the work...
> Yours,
> Linus Walleij

[PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

[Linus Walleij]

On Mon, Dec 9, 2013 at 11:34 AM, boris brezillon
<b.brezillon@overkiz.com> wrote:
> [Me]
>> This has been suggested under the name "GPIO hogs" in the past.
>>
>> It would work similar to how pinctrl hogs work by associating the
>> GPIO line the controller itself, using some specific string
>> like gpio-input-hogs = <...> / gpio-output-hogs = <...>;
>>
>> The gpiolib core will then grab and set up these before
>> returning from the registration call so noone ever gets a chance
>> to use them.
>
> One more question, and I'm done :).
>
> In which case should we use output-high or output-low config
> instead of gpio-output-hogs ?

This is specified in Documentation/pinctrl.txt under the
heading "GPIO mode pitfalls".

Basically: the generic pinconfig output-high/output-low are
for the case where this is a valid state for a Linux device
driver driving a piece of hardware, like an IP-block, which
is making use of these pins and during that usecase passes
through states the data sheet may call "GPIO mode",
but which are actually a way which the *device* uses
the pins, not independent GPIO lines, like, just some
1-bit line.

Yours,
Linus Walleij

[PATCH 6/9] ARM: at91/dt: add spi0 support to at91rm9200ek board

[Boris BREZILLON]

Add spi0 cs3 switch pinctrl pin definitions: this pin is used to select
between mmc0 slot0 and spi dataflash connected to cs3.

Enable spi0 controller and define the mtd_dataflash connected to cs0.

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek.dts |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index 2bad423..b3e7425 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -56,6 +56,13 @@
 							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
 					};
 				};
+
+				spi0 {
+					pinctrl_spi0_cs3_switch: spi0_cs3_switch-0 {
+						atmel,pins =
+							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
+					};
+				};
 			};
 
 			dbgu: serial at fffff200 {
@@ -119,6 +126,19 @@
 					wp-gpios = <&pioA 17 GPIO_ACTIVE_HIGH>;
 				};
 			};
+
+			spi0: spi at fffe0000 {
+				pinctrl-0 = <&pinctrl_spi0 &pinctrl_spi0_cs0>;
+				cs-gpios = <&pioA 3 GPIO_ACTIVE_HIGH>, <0>,
+					   <0>, <0>;
+				status = "okay";
+
+				mtd_dataflash at 0 {
+					compatible = "atmel,at45", "atmel,dataflash";
+					spi-max-frequency = <15000000>;
+					reg = <0>;
+				};
+			};
 		};
 
 		usb0: ohci at 00300000 {
-- 
1.7.9.5

[PATCH 6/9] ARM: at91/dt: add spi0 support to at91rm9200ek board

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:07 Wed 28 Aug     , Boris BREZILLON wrote:
> Add spi0 cs3 switch pinctrl pin definitions: this pin is used to select
> between mmc0 slot0 and spi dataflash connected to cs3.
> 
> Enable spi0 controller and define the mtd_dataflash connected to cs0.
> 
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>  arch/arm/boot/dts/at91rm9200ek.dts |   20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
> index 2bad423..b3e7425 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -56,6 +56,13 @@
>  							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(1))>;
>  					};
>  				};
> +
> +				spi0 {
> +					pinctrl_spi0_cs3_switch: spi0_cs3_switch-0 {
> +						atmel,pins =
> +							<AT91_PIOB 22 AT91_PERIPH_GPIO (AT91_PINCTRL_OUTPUT | AT91_PINCTRL_OUTPUT_VAL(0))>;
> +					};
same as mmc nack pinctrl is not for gpio default value

this is regulator
> +				};
>  			};
>  
>  			dbgu: serial at fffff200 {
> @@ -119,6 +126,19 @@
>  					wp-gpios = <&pioA 17 GPIO_ACTIVE_HIGH>;
>  				};
>  			};
> +
> +			spi0: spi at fffe0000 {
> +				pinctrl-0 = <&pinctrl_spi0 &pinctrl_spi0_cs0>;
> +				cs-gpios = <&pioA 3 GPIO_ACTIVE_HIGH>, <0>,
> +					   <0>, <0>;
> +				status = "okay";
> +
> +				mtd_dataflash at 0 {
> +					compatible = "atmel,at45", "atmel,dataflash";
> +					spi-max-frequency = <15000000>;
> +					reg = <0>;
> +				};
> +			};
>  		};
>  
>  		usb0: ohci at 00300000 {
> -- 
> 1.7.9.5
> 

[PATCH 7/9] ARM: at91/dt: add i2c devices connected to at91rm9200ek board

[Boris BREZILLON]

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek.dts |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
index b3e7425..fd2601a 100644
--- a/arch/arm/boot/dts/at91rm9200ek.dts
+++ b/arch/arm/boot/dts/at91rm9200ek.dts
@@ -147,6 +147,18 @@
 		};
 	};
 
+	i2c at 0 {
+		status = "okay";
+
+		ics1523 at 26 {
+			reg = <0x26>;
+		};
+
+		dac3550 at 4d {
+			reg = <0x4d>;
+		};
+	};
+
 	leds {
 		compatible = "gpio-leds";
 
-- 
1.7.9.5

[PATCH 7/9] ARM: at91/dt: add i2c devices connected to at91rm9200ek board

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:08 Wed 28 Aug     , Boris BREZILLON wrote:
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>  arch/arm/boot/dts/at91rm9200ek.dts |   12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
> index b3e7425..fd2601a 100644
> --- a/arch/arm/boot/dts/at91rm9200ek.dts
> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
> @@ -147,6 +147,18 @@
>  		};
>  	};
>  
> +	i2c at 0 {
> +		status = "okay";
> +
> +		ics1523 at 26 {
> +			reg = <0x26>;
> +		};
> +
> +		dac3550 at 4d {
> +			reg = <0x4d>;
missing compatible
> +		};
> +	};
> +
>  	leds {
>  		compatible = "gpio-leds";
>  
> -- 
> 1.7.9.5
> 

[PATCH 7/9] ARM: at91/dt: add i2c devices connected to at91rm9200ek board

[boris brezillon]

On 20/11/2013 16:01, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:08 Wed 28 Aug     , Boris BREZILLON wrote:
>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>>   arch/arm/boot/dts/at91rm9200ek.dts |   12 ++++++++++++
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/at91rm9200ek.dts b/arch/arm/boot/dts/at91rm9200ek.dts
>> index b3e7425..fd2601a 100644
>> --- a/arch/arm/boot/dts/at91rm9200ek.dts
>> +++ b/arch/arm/boot/dts/at91rm9200ek.dts
>> @@ -147,6 +147,18 @@
>>   		};
>>   	};
>>   
>> +	i2c at 0 {
>> +		status = "okay";
>> +
>> +		ics1523 at 26 {
>> +			reg = <0x26>;
>> +		};
>> +
>> +		dac3550 at 4d {
>> +			reg = <0x4d>;
> missing compatible

I can't find any matching compatible for these devices.
Do you know what should be used ?

>> +		};
>> +	};
>> +
>>   	leds {
>>   		compatible = "gpio-leds";
>>   
>> -- 
>> 1.7.9.5
>>

[PATCH 8/9] ARM: at91/dt: add new at91rm9200ek_mmc board

[Boris BREZILLON]

Add a new at91rm9200ek_mmc board (based on at91rm9200ek board) which enables
mmc0/slot0.

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek_mmc.dts |   23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91rm9200ek_mmc.dts

diff --git a/arch/arm/boot/dts/at91rm9200ek_mmc.dts b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
new file mode 100644
index 0000000..c87a861
--- /dev/null
+++ b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
@@ -0,0 +1,23 @@
+/*
+ * at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit with
+ *                    an MMC slot
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon@overkiz.com>
+ *
+ * Licensed under GPLv2 only
+ */
+/dts-v1/;
+#include "at91rm9200ek.dts"
+
+/ {
+	model = "Atmel AT91RM9200 evaluation kit with MMC slot";
+	compatible = "atmel,at91rm9200ek-mmc", "atmel,at91rm9200ek", "atmel,at91rm9200";
+
+	ahb {
+		apb {
+			mmc0: mmc at fffb4000 {
+				status = "okay";
+			};
+		};
+	};
+};
-- 
1.7.9.5

[PATCH 8/9] ARM: at91/dt: add new at91rm9200ek_mmc board

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:37 Wed 28 Aug     , Boris BREZILLON wrote:
> Add a new at91rm9200ek_mmc board (based on at91rm9200ek board) which enables
> mmc0/slot0.

no for multiple dts

this need to handle at user space level

Best Regards,
J.
> 
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
>  arch/arm/boot/dts/at91rm9200ek_mmc.dts |   23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 arch/arm/boot/dts/at91rm9200ek_mmc.dts
> 
> diff --git a/arch/arm/boot/dts/at91rm9200ek_mmc.dts b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
> new file mode 100644
> index 0000000..c87a861
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
> @@ -0,0 +1,23 @@
> +/*
> + * at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit with
> + *                    an MMC slot
> + *
> + *  Copyright (C) 2013 Boris BREZILLON <b.brezillon@overkiz.com>
> + *
> + * Licensed under GPLv2 only
> + */
> +/dts-v1/;
> +#include "at91rm9200ek.dts"
> +
> +/ {
> +	model = "Atmel AT91RM9200 evaluation kit with MMC slot";
> +	compatible = "atmel,at91rm9200ek-mmc", "atmel,at91rm9200ek", "atmel,at91rm9200";
> +
> +	ahb {
> +		apb {
> +			mmc0: mmc at fffb4000 {
> +				status = "okay";
> +			};
> +		};
> +	};
> +};
> -- 
> 1.7.9.5
> 

[PATCH 8/9] ARM: at91/dt: add new at91rm9200ek_mmc board

[boris brezillon]

On 20/11/2013 16:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:37 Wed 28 Aug     , Boris BREZILLON wrote:
>> Add a new at91rm9200ek_mmc board (based on at91rm9200ek board) which enables
>> mmc0/slot0.
> no for multiple dts
>
> this need to handle at user space level

You mean, by controlling the regulator using the sysfs interface, or by 
loading
only the appropriate driver ?

What if both drivers are loaded (or not compiled as modules) ?
This will lead to one device being unusable (and maybe even worst)...

Please explain what you had in mind ?

>
> Best Regards,
> J.
>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>> ---
>>   arch/arm/boot/dts/at91rm9200ek_mmc.dts |   23 +++++++++++++++++++++++
>>   1 file changed, 23 insertions(+)
>>   create mode 100644 arch/arm/boot/dts/at91rm9200ek_mmc.dts
>>
>> diff --git a/arch/arm/boot/dts/at91rm9200ek_mmc.dts b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
>> new file mode 100644
>> index 0000000..c87a861
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
>> @@ -0,0 +1,23 @@
>> +/*
>> + * at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit with
>> + *                    an MMC slot
>> + *
>> + *  Copyright (C) 2013 Boris BREZILLON <b.brezillon@overkiz.com>
>> + *
>> + * Licensed under GPLv2 only
>> + */
>> +/dts-v1/;
>> +#include "at91rm9200ek.dts"
>> +
>> +/ {
>> +	model = "Atmel AT91RM9200 evaluation kit with MMC slot";
>> +	compatible = "atmel,at91rm9200ek-mmc", "atmel,at91rm9200ek", "atmel,at91rm9200";
>> +
>> +	ahb {
>> +		apb {
>> +			mmc0: mmc at fffb4000 {
>> +				status = "okay";
>> +			};
>> +		};
>> +	};
>> +};
>> -- 
>> 1.7.9.5
>>

[PATCH 8/9] ARM: at91/dt: add new at91rm9200ek_mmc board

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:31 Wed 20 Nov     , boris brezillon wrote:
> On 20/11/2013 16:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 14:37 Wed 28 Aug     , Boris BREZILLON wrote:
> >>Add a new at91rm9200ek_mmc board (based on at91rm9200ek board) which enables
> >>mmc0/slot0.
> >no for multiple dts
> >
> >this need to handle at user space level
> 
> You mean, by controlling the regulator using the sysfs interface, or
> by loading
> only the appropriate driver ?
load the partial dts via userspace
> 
> What if both drivers are loaded (or not compiled as modules) ?
> This will lead to one device being unusable (and maybe even worst)...
> 
this will never be the case

Best Regards,
J.
> Please explain what you had in mind ?
> 
> >
> >Best Regards,
> >J.
> >>Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> >>---
> >>  arch/arm/boot/dts/at91rm9200ek_mmc.dts |   23 +++++++++++++++++++++++
> >>  1 file changed, 23 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/at91rm9200ek_mmc.dts
> >>
> >>diff --git a/arch/arm/boot/dts/at91rm9200ek_mmc.dts b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
> >>new file mode 100644
> >>index 0000000..c87a861
> >>--- /dev/null
> >>+++ b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
> >>@@ -0,0 +1,23 @@
> >>+/*
> >>+ * at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit with
> >>+ *                    an MMC slot
> >>+ *
> >>+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon@overkiz.com>
> >>+ *
> >>+ * Licensed under GPLv2 only
> >>+ */
> >>+/dts-v1/;
> >>+#include "at91rm9200ek.dts"
> >>+
> >>+/ {
> >>+	model = "Atmel AT91RM9200 evaluation kit with MMC slot";
> >>+	compatible = "atmel,at91rm9200ek-mmc", "atmel,at91rm9200ek", "atmel,at91rm9200";
> >>+
> >>+	ahb {
> >>+		apb {
> >>+			mmc0: mmc at fffb4000 {
> >>+				status = "okay";
> >>+			};
> >>+		};
> >>+	};
> >>+};
> >>-- 
> >>1.7.9.5
> >>
> 

[PATCH 8/9] ARM: at91/dt: add new at91rm9200ek_mmc board

[Nicolas Ferre]

On 20/11/2013 18:27, Jean-Christophe PLAGNIOL-VILLARD :
> On 17:31 Wed 20 Nov     , boris brezillon wrote:
>> On 20/11/2013 16:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 14:37 Wed 28 Aug     , Boris BREZILLON wrote:
>>>> Add a new at91rm9200ek_mmc board (based on at91rm9200ek board) which enables
>>>> mmc0/slot0.
>>> no for multiple dts
>>>
>>> this need to handle at user space level
>>
>> You mean, by controlling the regulator using the sysfs interface, or
>> by loading
>> only the appropriate driver ?
> load the partial dts via userspace

Right, but Jean-Christophe, we know that DT fragments are not available 
in mainline yet (even if the effort is ongoing). So what should we do in 
the meantime?

>> What if both drivers are loaded (or not compiled as modules) ?
>> This will lead to one device being unusable (and maybe even worst)...
>>
> this will never be the case

Can you please elaborate? It is a bit frustrating to have to ask you 
again and again to explain more your thoughts...

Bye,

> Best Regards,
> J.
>> Please explain what you had in mind ?
>>
>>>
>>> Best Regards,
>>> J.
>>>> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
>>>> ---
>>>>   arch/arm/boot/dts/at91rm9200ek_mmc.dts |   23 +++++++++++++++++++++++
>>>>   1 file changed, 23 insertions(+)
>>>>   create mode 100644 arch/arm/boot/dts/at91rm9200ek_mmc.dts
>>>>
>>>> diff --git a/arch/arm/boot/dts/at91rm9200ek_mmc.dts b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
>>>> new file mode 100644
>>>> index 0000000..c87a861
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/at91rm9200ek_mmc.dts
>>>> @@ -0,0 +1,23 @@
>>>> +/*
>>>> + * at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit with
>>>> + *                    an MMC slot
>>>> + *
>>>> + *  Copyright (C) 2013 Boris BREZILLON <b.brezillon@overkiz.com>
>>>> + *
>>>> + * Licensed under GPLv2 only
>>>> + */
>>>> +/dts-v1/;
>>>> +#include "at91rm9200ek.dts"
>>>> +
>>>> +/ {
>>>> +	model = "Atmel AT91RM9200 evaluation kit with MMC slot";
>>>> +	compatible = "atmel,at91rm9200ek-mmc", "atmel,at91rm9200ek", "atmel,at91rm9200";
>>>> +
>>>> +	ahb {
>>>> +		apb {
>>>> +			mmc0: mmc at fffb4000 {
>>>> +				status = "okay";
>>>> +			};
>>>> +		};
>>>> +	};
>>>> +};
>>>> --
>>>> 1.7.9.5
>>>>
>>
>


-- 
Nicolas Ferre

[PATCH 9/9] ARM: at91/dt: add new at91rm9200ek_dataflash board

[Boris BREZILLON]

Add a new at91rm9200ek_dataflash board (based on at91rm9200ek board) which
enables dataflash connected to cs3 of spi0.

Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
---
 arch/arm/boot/dts/at91rm9200ek_dataflash.dts |   33 ++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 arch/arm/boot/dts/at91rm9200ek_dataflash.dts

diff --git a/arch/arm/boot/dts/at91rm9200ek_dataflash.dts b/arch/arm/boot/dts/at91rm9200ek_dataflash.dts
new file mode 100644
index 0000000..a43412e
--- /dev/null
+++ b/arch/arm/boot/dts/at91rm9200ek_dataflash.dts
@@ -0,0 +1,33 @@
+/*
+ * at91rm9200ek.dts - Device Tree file for Atmel AT91RM9200 evaluation kit with
+ *                    2 SPI dataflash
+ *
+ *  Copyright (C) 2013 Boris BREZILLON <b.brezillon@overkiz.com>
+ *
+ * Licensed under GPLv2 only
+ */
+/dts-v1/;
+#include "at91rm9200ek.dts"
+
+/ {
+	model = "Atmel AT91RM9200 evaluation kit with 2 SPI dataflash";
+	compatible = "atmel,at91rm9200ek-dataflash", "atmel,at91rm9200ek", "atmel,at91rm9200";
+
+	ahb {
+		apb {
+			spi0: spi at fffe0000 {
+				pinctrl-0 = <&pinctrl_spi0 &pinctrl_spi0_cs0
+					     &pinctrl_spi0_cs3
+					     &pinctrl_spi0_cs3_switch>;
+				cs-gpios = <&pioA 3 GPIO_ACTIVE_HIGH>, <0>,
+					   <0>, <&pioA 6 GPIO_ACTIVE_HIGH>;
+
+				mtd_dataflash at 3 {
+					compatible = "atmel,at45", "atmel,dataflash";
+					spi-max-frequency = <15000000>;
+					reg = <3>;
+				};
+			};
+		};
+	};
+};
-- 
1.7.9.5