From mboxrd@z Thu Jan 1 00:00:00 1970 From: b.brezillon@overkiz.com (boris brezillon) Date: Tue, 26 Nov 2013 18:55:52 +0100 Subject: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board In-Reply-To: References: <1377687640-10529-1-git-send-email-b.brezillon@overkiz.com> <1377687995-10758-1-git-send-email-b.brezillon@overkiz.com> <20131120145926.GE14627@ns203013.ovh.net> <528CDFFB.1020601@overkiz.com> <528DE1C4.6060900@overkiz.com> Message-ID: <5294E0A8.20303@overkiz.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.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 > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: boris brezillon Subject: Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board Date: Tue, 26 Nov 2013 18:55:52 +0100 Message-ID: <5294E0A8.20303@overkiz.com> References: <1377687640-10529-1-git-send-email-b.brezillon@overkiz.com> <1377687995-10758-1-git-send-email-b.brezillon@overkiz.com> <20131120145926.GE14627@ns203013.ovh.net> <528CDFFB.1020601@overkiz.com> <528DE1C4.6060900@overkiz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Linus Walleij Cc: Jean-Christophe PLAGNIOL-VILLARD , Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , Russell King , Nicolas Ferre , Joachim Eastwood , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org Hello Linus, Sorry for the noise, my mail was filtered by several ML because of some= =20 HTML contents. Le 26/11/2013 14:46, Linus Walleij a =E9crit : > On Thu, Nov 21, 2013 at 11:34 AM, boris brezillon > 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= =2E >> >> 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 th= e other: >> - PB22 set to high level enables slot0 of mmc0 (connect mmc signal= s 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=20 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=20 http://www.alliedelec.com/images/products/datasheets/bm/ATMEL/70123901.= pdf,=20 and you'll find the switch schematic at page 26. Here is the switch datasheet :=20 http://pdf1.alldatasheet.fr/datasheet-pdf/view/90971/PERICOM/PI5A100Q.h= tml If I understand correctly, you're suggesting to retrieve the PB22 pin=20 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=20 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=20 (or board init function) depending on the MTD_AT91_DATAFLASH_CARD (=20 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= =20 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" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757020Ab3KZSEA (ORCPT ); Tue, 26 Nov 2013 13:04:00 -0500 Received: from 2.mo6.mail-out.ovh.net ([46.105.76.65]:47271 "EHLO mo6.mail-out.ovh.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756610Ab3KZSD4 (ORCPT ); Tue, 26 Nov 2013 13:03:56 -0500 Message-ID: <5294E0A8.20303@overkiz.com> Date: Tue, 26 Nov 2013 18:55:52 +0100 From: boris brezillon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Linus Walleij CC: Jean-Christophe PLAGNIOL-VILLARD , Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , Russell King , Nicolas Ferre , Joachim Eastwood , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board References: <1377687640-10529-1-git-send-email-b.brezillon@overkiz.com> <1377687995-10758-1-git-send-email-b.brezillon@overkiz.com> <20131120145926.GE14627@ns203013.ovh.net> <528CDFFB.1020601@overkiz.com> <528DE1C4.6060900@overkiz.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 16276290529107015901 X-Ovh-Remote: 78.236.240.82 (cha74-5-78-236-240-82.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiledrjeekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeiledrjeekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 > 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