From: Boris BREZILLON <hidden> Date: 2013-08-28 11:13:12
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
From: Boris BREZILLON <hidden> Date: 2013-08-28 11:04:23
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 5 +++++
1 file changed, 5 insertions(+)
From: boris brezillon <hidden> Date: 2013-11-18 08:40:11
On 28/08/2013 13:03, Boris BREZILLON wrote:
quoted hunk
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 5 +++++
1 file changed, 5 insertions(+)
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.
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.
From: Boris BREZILLON <hidden> Date: 2013-08-28 11:07:22
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
From: boris brezillon <hidden> Date: 2013-11-20 16:15:43
On 20/11/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 13:06 Wed 28 Aug , Boris BREZILLON wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
On 20/11/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD wrote:
quoted
On 13:06 Wed 28 Aug , Boris BREZILLON wrote:
quoted
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
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.
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
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
On Thu, Nov 21, 2013 at 11:34 AM, boris brezillon
[off-list ref] wrote:
On 21/11/2013 10:48, Linus Walleij wrote:
quoted
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
From: boris brezillon <hidden> Date: 2013-11-26 18:04:00
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
[off-list ref] wrote:
quoted
On 21/11/2013 10:48, Linus Walleij wrote:
quoted
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 ...
quoted
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)
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).
quoted
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
From: Boris BREZILLON <hidden> Date: 2013-08-28 11:08:19
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
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 <redacted>
---
arch/arm/boot/dts/at91rm9200ek.dts | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
From: boris brezillon <hidden> Date: 2013-11-20 18:59:38
On 20/11/2013 16:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 14:37 Wed 28 Aug , Boris BREZILLON wrote:
quoted
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 ?
From: Nicolas Ferre <hidden> Date: 2013-11-21 08:44:16
On 20/11/2013 18:27, Jean-Christophe PLAGNIOL-VILLARD :
On 17:31 Wed 20 Nov , boris brezillon wrote:
quoted
On 20/11/2013 16:02, Jean-Christophe PLAGNIOL-VILLARD wrote:
quoted
On 14:37 Wed 28 Aug , Boris BREZILLON wrote:
quoted
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?
quoted
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,
From: Boris BREZILLON <hidden> Date: 2013-08-28 12:39:40
Add a new at91rm9200ek_dataflash board (based on at91rm9200ek board) which
enables dataflash connected to cs3 of spi0.
Signed-off-by: Boris BREZILLON <redacted>
---
arch/arm/boot/dts/at91rm9200ek_dataflash.dts | 33 ++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 arch/arm/boot/dts/at91rm9200ek_dataflash.dts