All of lore.kernel.org
 help / color / mirror / Atom feed
From: b.brezillon@overkiz.com (boris brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board
Date: Tue, 26 Nov 2013 18:55:52 +0100	[thread overview]
Message-ID: <5294E0A8.20303@overkiz.com> (raw)
In-Reply-To: <CACRpkdZdweyWJefttiuiYAJ9qhahLbnj7eHUiLV_83UA41X_uQ@mail.gmail.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: boris brezillon <b.brezillon-ZNYIgs0QAGpBDgjK7y7TUQ@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Jean-Christophe PLAGNIOL-VILLARD
	<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Ian Campbell
	<ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Nicolas Ferre
	<nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
	Joachim Eastwood
	<manabian-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board
Date: Tue, 26 Nov 2013 18:55:52 +0100	[thread overview]
Message-ID: <5294E0A8.20303@overkiz.com> (raw)
In-Reply-To: <CACRpkdZdweyWJefttiuiYAJ9qhahLbnj7eHUiLV_83UA41X_uQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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-ZNYIgs0QAGpBDgjK7y7TUQ@public.gmane.org>  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

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: boris brezillon <b.brezillon@overkiz.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Rob Herring <rob.herring@calxeda.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Ian Campbell <ian.campbell@citrix.com>,
	Russell King <linux@arm.linux.org.uk>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Joachim Eastwood <manabian@gmail.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board
Date: Tue, 26 Nov 2013 18:55:52 +0100	[thread overview]
Message-ID: <5294E0A8.20303@overkiz.com> (raw)
In-Reply-To: <CACRpkdZdweyWJefttiuiYAJ9qhahLbnj7eHUiLV_83UA41X_uQ@mail.gmail.com>

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


  reply	other threads:[~2013-11-26 17:55 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28 11:00 [PATCH 0/9] ARM: at91/dt: add missing devices to rm9200ek board Boris BREZILLON
2013-08-28 11:00 ` Boris BREZILLON
2013-08-28 11:02 ` [PATCH 1/9] ARM: at91/dt: add rm9200 spi0 chip select pins definitions Boris BREZILLON
2013-08-28 11:02   ` Boris BREZILLON
2013-11-20 14:56   ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 14:56     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 14:56     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 15:59     ` boris brezillon
2013-11-20 15:59       ` boris brezillon
2013-11-20 17:05       ` boris brezillon
2013-11-20 17:05         ` boris brezillon
2013-08-28 11:03 ` [PATCH 2/9] ARM: at91/dt: add ethernet phy to at91rm9200ek board Boris BREZILLON
2013-08-28 11:03   ` Boris BREZILLON
2013-11-18  8:39   ` boris brezillon
2013-11-18  8:39     ` boris brezillon
2013-11-18  8:39     ` boris brezillon
2013-08-28 11:04 ` [PATCH 3/9] ARM: at91/dt: add usb1 vbus and pullup pins Boris BREZILLON
2013-08-28 11:04   ` Boris BREZILLON
2013-11-20 14:57   ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 14:57     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 14:57     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 15:48     ` boris brezillon
2013-11-20 15:48       ` boris brezillon
2013-11-20 15:48       ` boris brezillon
2013-08-28 11:05 ` [PATCH 4/9] ARM: at91/dt: add atmel, pullup-gpio to at91rm9200ek usb1 definition Boris BREZILLON
2013-08-28 11:05   ` [PATCH 4/9] ARM: at91/dt: add atmel,pullup-gpio " Boris BREZILLON
2013-08-28 11:06 ` [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board Boris BREZILLON
2013-08-28 11:06   ` Boris BREZILLON
2013-11-20 14:59   ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 14:59     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 14:59     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 16:14     ` boris brezillon
2013-11-20 16:14       ` boris brezillon
2013-11-20 17:20       ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 17:20         ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 17:20         ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-21  9:48       ` Linus Walleij
2013-11-21  9:48         ` Linus Walleij
2013-11-21 10:34         ` boris brezillon
2013-11-21 10:34           ` boris brezillon
2013-11-26 13:46           ` Linus Walleij
2013-11-26 13:46             ` Linus Walleij
2013-11-26 13:46             ` Linus Walleij
2013-11-26 17:55             ` boris brezillon [this message]
2013-11-26 17:55               ` boris brezillon
2013-11-26 17:55               ` boris brezillon
     [not found]             ` <5294D64D.7000100@overkiz.com>
2013-11-29 10:03               ` Linus Walleij
2013-11-29 10:03                 ` Linus Walleij
2013-11-29 10:30                 ` boris brezillon
2013-11-29 10:30                   ` boris brezillon
2013-11-29 10:30                   ` boris brezillon
2013-11-29 13:31                   ` Linus Walleij
2013-11-29 13:31                     ` Linus Walleij
2013-11-29 15:30                     ` boris brezillon
2013-11-29 15:30                       ` boris brezillon
2013-12-09 10:34                     ` boris brezillon
2013-12-09 10:34                       ` boris brezillon
2013-12-09 10:34                       ` boris brezillon
2013-12-12 17:52                       ` Linus Walleij
2013-12-12 17:52                         ` Linus Walleij
2013-08-28 11:07 ` [PATCH 6/9] ARM: at91/dt: add spi0 " Boris BREZILLON
2013-08-28 11:07   ` Boris BREZILLON
2013-11-20 15:00   ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 15:00     ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-28 11:08 ` [PATCH 7/9] ARM: at91/dt: add i2c devices connected " Boris BREZILLON
2013-08-28 11:08   ` Boris BREZILLON
2013-11-20 15:01   ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 15:01     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 16:17     ` boris brezillon
2013-11-20 16:17       ` boris brezillon
2013-08-28 12:37 ` [PATCH 8/9] ARM: at91/dt: add new at91rm9200ek_mmc board Boris BREZILLON
2013-08-28 12:37   ` Boris BREZILLON
2013-11-20 15:02   ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 15:02     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 15:02     ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 16:31     ` boris brezillon
2013-11-20 16:31       ` boris brezillon
2013-11-20 16:31       ` boris brezillon
2013-11-20 17:27       ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 17:27         ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-20 17:27         ` Jean-Christophe PLAGNIOL-VILLARD
2013-11-21  8:44         ` Nicolas Ferre
2013-11-21  8:44           ` Nicolas Ferre
2013-11-21  8:44           ` Nicolas Ferre
2013-08-28 12:38 ` [PATCH 9/9] ARM: at91/dt: add new at91rm9200ek_dataflash board Boris BREZILLON
2013-08-28 12:38   ` Boris BREZILLON

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5294E0A8.20303@overkiz.com \
    --to=b.brezillon@overkiz.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.