From: Ulf Hansson <ulf.hansson@linaro.org> To: Arnd Bergmann <arnd@arndb.de> Cc: Tomasz Figa <tomasz.figa@gmail.com>, Tomasz Figa <t.figa@samsung.com>, Olof Johansson <olof@lixom.net>, linux-mmc <linux-mmc@vger.kernel.org>, devicetree@vger.kernel.org, Russell King - ARM Linux <linux@arm.linux.org.uk>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, robh+dt@kernel.org, mark.rutland@arm.com, Pawel Moll <pawel.moll@arm.com>, Ian Campbell <ijc+devicetree@hellion.org.uk>, Kumar Gala <galak@codeaurora.org>, Chris Ball <chris@printf.net>, Sascha Hauer <s.hauer@pengutronix.de>, Fabio Estevam <festevam@gmail.com> Subject: Re: [PATCH 1/3] mmc: add support for power-on sequencing through DT Date: Thu, 13 Feb 2014 09:56:56 +0100 [thread overview] Message-ID: <CAPDyKFo9Xpxe0XzevPEeaofLeCNivnf3R_RttToP2h3aFyB4Yw@mail.gmail.com> (raw) In-Reply-To: <201401281148.10670.arnd@arndb.de> On 28 January 2014 11:48, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 28 January 2014, Ulf Hansson wrote: >> On 28 January 2014 01:59, Tomasz Figa <tomasz.figa@gmail.com> wrote: >> > On 27.01.2014 11:19, Ulf Hansson wrote: >> >> There is already a host capability that I think we could use to handle >> >> this. MMC_CAP_NONREMOVABLE, the corresponding DT binding string is >> >> "non-removable", and it may be set per host device. >> >> >> >> Using this cap means the mmc_rescan process that runs to detect new >> >> cards, will only be executed once and during boot. So, we need to make >> >> sure all resources and powers are provided to the card at this point. >> >> Otherwise the card will not be detected. >> > >> > I don't quite like this requirement, especially if you consider >> > multi-platform kernels where a lot of drivers is going to be provided as >> > modules. WLAN drivers are especially good candidates. This means that even >> > if the card is powered off at boot-up, if user (or init system) loads >> > appropriate module, which powers the chip on, MMC core must be able to >> > notice this. >> >> To be able to detect the card, the WLAN driver doesn't have to be >> probed, only the "power controller" driver. I suppose this is were it >> becomes a bit tricky. >> >> Somehow the mmc core needs to be involved in the probe process of the >> power controller driver. Could perhaps the power controller bus be >> located in the mmc core and thus the power controller driver needs to >> register itself by using a new API from the mmc core? Similar how SDIO >> func driver's register themselves. > > I think there is another option, which does have its own pros and cons: > We could move all the power handling back into the sdio function driver > if we allow a secondary detection path using DT rather than the probing > of the SDIO bus. Essentially you'd have to list the class/vendor/device > ID for each function that cannot be autodetected in DT, and have the > SDIO core pretend that it found the device just by looking at the > device nodes, and register the struct sdio_func so it can be bound to > the driver. The driver then does all the power handling in a device > specific way. At some point the hardware gets registered at the > mmc host, and the sdio core connects the bus state to the already present > sdio_func, possibly notifying the function driver that it has become > usable. It seems like an option we could try. There are some tricky parts that needs to be taken care of by the mmc/sdio core, regarding the probe/removal and the suspend/resume sequence, but I suppose it should be possible. A minor concern is how do we handle devices that are fully powered at boot? Unless the sdio func driver will be loaded we can't power off them, right? Do we need to cover this case, do you think? > > Obviously, this can only work for CAP_NONREMOVABLE devices, but those > are exactly the ones we are worried about here. The advantage is that > the power sequencing for a particular device can then be in device > specific code and can have an arbitrarily complex in the driver without > needing the mmc code to handle all possible corner cases. Agree! I think a removable SDIO card won't l need this additional power controller mechanism. Kind regards Uffe > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: ulf.hansson@linaro.org (Ulf Hansson) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/3] mmc: add support for power-on sequencing through DT Date: Thu, 13 Feb 2014 09:56:56 +0100 [thread overview] Message-ID: <CAPDyKFo9Xpxe0XzevPEeaofLeCNivnf3R_RttToP2h3aFyB4Yw@mail.gmail.com> (raw) In-Reply-To: <201401281148.10670.arnd@arndb.de> On 28 January 2014 11:48, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 28 January 2014, Ulf Hansson wrote: >> On 28 January 2014 01:59, Tomasz Figa <tomasz.figa@gmail.com> wrote: >> > On 27.01.2014 11:19, Ulf Hansson wrote: >> >> There is already a host capability that I think we could use to handle >> >> this. MMC_CAP_NONREMOVABLE, the corresponding DT binding string is >> >> "non-removable", and it may be set per host device. >> >> >> >> Using this cap means the mmc_rescan process that runs to detect new >> >> cards, will only be executed once and during boot. So, we need to make >> >> sure all resources and powers are provided to the card at this point. >> >> Otherwise the card will not be detected. >> > >> > I don't quite like this requirement, especially if you consider >> > multi-platform kernels where a lot of drivers is going to be provided as >> > modules. WLAN drivers are especially good candidates. This means that even >> > if the card is powered off at boot-up, if user (or init system) loads >> > appropriate module, which powers the chip on, MMC core must be able to >> > notice this. >> >> To be able to detect the card, the WLAN driver doesn't have to be >> probed, only the "power controller" driver. I suppose this is were it >> becomes a bit tricky. >> >> Somehow the mmc core needs to be involved in the probe process of the >> power controller driver. Could perhaps the power controller bus be >> located in the mmc core and thus the power controller driver needs to >> register itself by using a new API from the mmc core? Similar how SDIO >> func driver's register themselves. > > I think there is another option, which does have its own pros and cons: > We could move all the power handling back into the sdio function driver > if we allow a secondary detection path using DT rather than the probing > of the SDIO bus. Essentially you'd have to list the class/vendor/device > ID for each function that cannot be autodetected in DT, and have the > SDIO core pretend that it found the device just by looking at the > device nodes, and register the struct sdio_func so it can be bound to > the driver. The driver then does all the power handling in a device > specific way. At some point the hardware gets registered at the > mmc host, and the sdio core connects the bus state to the already present > sdio_func, possibly notifying the function driver that it has become > usable. It seems like an option we could try. There are some tricky parts that needs to be taken care of by the mmc/sdio core, regarding the probe/removal and the suspend/resume sequence, but I suppose it should be possible. A minor concern is how do we handle devices that are fully powered at boot? Unless the sdio func driver will be loaded we can't power off them, right? Do we need to cover this case, do you think? > > Obviously, this can only work for CAP_NONREMOVABLE devices, but those > are exactly the ones we are worried about here. The advantage is that > the power sequencing for a particular device can then be in device > specific code and can have an arbitrarily complex in the driver without > needing the mmc code to handle all possible corner cases. Agree! I think a removable SDIO card won't l need this additional power controller mechanism. Kind regards Uffe > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-02-13 8:56 UTC|newest] Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-01-20 3:56 [PATCH 0/3] RFC/RFT: Powering on MMC Wifi/BT modules in MMC core Olof Johansson 2014-01-20 3:56 ` Olof Johansson 2014-01-20 3:56 ` [PATCH 1/3] mmc: add support for power-on sequencing through DT Olof Johansson 2014-01-20 3:56 ` Olof Johansson 2014-01-20 8:44 ` Ulf Hansson 2014-01-20 8:44 ` Ulf Hansson 2014-01-20 19:13 ` Olof Johansson 2014-01-20 19:13 ` Olof Johansson 2014-01-21 8:55 ` Ulf Hansson 2014-01-21 8:55 ` Ulf Hansson 2014-01-21 18:14 ` Olof Johansson 2014-01-21 18:14 ` Olof Johansson 2014-01-22 11:30 ` Mark Brown 2014-01-22 11:30 ` Mark Brown 2014-01-20 16:36 ` Mark Brown 2014-01-20 16:36 ` Mark Brown 2014-01-20 16:48 ` Russell King - ARM Linux 2014-01-20 16:48 ` Russell King - ARM Linux 2014-01-20 17:03 ` Fabio Estevam 2014-01-20 17:03 ` Fabio Estevam 2014-01-20 17:16 ` Russell King - ARM Linux 2014-01-20 17:16 ` Russell King - ARM Linux 2014-01-20 18:47 ` Fabio Estevam 2014-01-20 18:47 ` Fabio Estevam 2014-01-21 19:19 ` Russell King - ARM Linux 2014-01-21 19:19 ` Russell King - ARM Linux 2014-01-24 17:35 ` Fabio Estevam 2014-01-24 17:35 ` Fabio Estevam 2014-01-27 8:43 ` Jyri Sarha 2014-01-27 8:43 ` Jyri Sarha 2014-01-27 8:54 ` Chen-Yu Tsai 2014-01-27 8:54 ` Chen-Yu Tsai 2014-01-27 9:48 ` Jyri Sarha 2014-01-27 9:48 ` Jyri Sarha 2014-01-20 18:58 ` Arnd Bergmann 2014-01-20 18:58 ` Arnd Bergmann [not found] ` <201401201958.57997.arnd-r2nGTMty4D4@public.gmane.org> 2014-01-20 19:04 ` Olof Johansson 2014-01-20 19:04 ` Olof Johansson 2014-01-20 19:12 ` Arnd Bergmann 2014-01-20 19:12 ` Arnd Bergmann 2014-01-20 19:14 ` Fabio Estevam 2014-01-20 19:14 ` Fabio Estevam 2014-01-20 19:14 ` Olof Johansson 2014-01-20 19:14 ` Olof Johansson 2014-01-21 7:24 ` Sascha Hauer 2014-01-21 7:24 ` Sascha Hauer 2014-01-21 7:25 ` Sascha Hauer 2014-01-21 7:25 ` Sascha Hauer 2014-01-21 18:34 ` Tomasz Figa 2014-01-21 18:34 ` Tomasz Figa 2014-01-21 21:30 ` Olof Johansson 2014-01-21 21:30 ` Olof Johansson 2014-01-21 21:39 ` Tomasz Figa 2014-01-21 21:39 ` Tomasz Figa 2014-01-26 17:26 ` Tomasz Figa 2014-01-26 17:26 ` Tomasz Figa 2014-01-27 10:19 ` Ulf Hansson 2014-01-27 10:19 ` Ulf Hansson 2014-01-28 0:59 ` Tomasz Figa 2014-01-28 0:59 ` Tomasz Figa 2014-01-28 1:08 ` Chris Ball 2014-01-28 1:08 ` Chris Ball 2014-01-28 10:06 ` Ulf Hansson 2014-01-28 10:06 ` Ulf Hansson 2014-01-28 10:48 ` Arnd Bergmann 2014-01-28 10:48 ` Arnd Bergmann 2014-02-12 18:33 ` Mark Brown 2014-02-12 18:33 ` Mark Brown 2014-02-13 8:56 ` Ulf Hansson [this message] 2014-02-13 8:56 ` Ulf Hansson 2014-02-13 9:01 ` Tomasz Figa 2014-02-13 9:01 ` Tomasz Figa 2014-02-13 10:42 ` Russell King - ARM Linux 2014-02-13 10:42 ` Russell King - ARM Linux 2014-02-13 12:48 ` Arnd Bergmann 2014-02-13 12:48 ` Arnd Bergmann 2014-02-13 14:41 ` Russell King - ARM Linux 2014-02-13 14:41 ` Russell King - ARM Linux 2014-02-13 16:13 ` Arnd Bergmann 2014-02-13 16:13 ` Arnd Bergmann 2014-02-13 17:31 ` Olof Johansson 2014-02-13 17:31 ` Olof Johansson 2014-02-15 12:18 ` Arnd Bergmann 2014-02-15 12:18 ` Arnd Bergmann 2014-02-15 12:27 ` Russell King - ARM Linux 2014-02-15 12:27 ` Russell King - ARM Linux 2014-02-15 13:09 ` Arnd Bergmann 2014-02-15 13:09 ` Arnd Bergmann 2014-02-15 13:22 ` Tomasz Figa 2014-02-15 13:22 ` Tomasz Figa 2014-02-15 16:21 ` Arnd Bergmann 2014-02-15 16:21 ` Arnd Bergmann 2014-02-15 20:52 ` Russell King - ARM Linux 2014-02-15 20:52 ` Russell King - ARM Linux 2014-02-15 21:35 ` Tomasz Figa 2014-02-15 21:35 ` Tomasz Figa 2014-02-15 22:03 ` Russell King - ARM Linux 2014-02-15 22:03 ` Russell King - ARM Linux 2014-02-17 13:00 ` Arnd Bergmann 2014-02-17 13:00 ` Arnd Bergmann 2014-02-17 23:25 ` Mark Brown 2014-02-17 23:25 ` Mark Brown 2014-01-20 3:56 ` [PATCH 2/3] mmc: dw_mmc: call mmc_of_parse to fill in common options Olof Johansson 2014-01-20 3:56 ` Olof Johansson 2014-01-20 4:53 ` Jaehoon Chung 2014-01-20 4:53 ` Jaehoon Chung 2014-01-20 3:56 ` [PATCH 3/3] ARM: dts: exynos5250-snow: Enable wifi power-on Olof Johansson 2014-01-20 3:56 ` Olof Johansson 2014-01-30 21:49 ` [PATCH 0/3] RFC/RFT: Powering on MMC Wifi/BT modules in MMC core Russell King - ARM Linux 2014-01-30 21:49 ` Russell King - ARM Linux 2014-02-01 16:14 ` Russell King - ARM Linux 2014-02-01 16:14 ` Russell King - ARM Linux 2014-02-13 10:36 ` Russell King - ARM Linux 2014-02-13 10:36 ` Russell King - ARM Linux
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=CAPDyKFo9Xpxe0XzevPEeaofLeCNivnf3R_RttToP2h3aFyB4Yw@mail.gmail.com \ --to=ulf.hansson@linaro.org \ --cc=arnd@arndb.de \ --cc=chris@printf.net \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=galak@codeaurora.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=mark.rutland@arm.com \ --cc=olof@lixom.net \ --cc=pawel.moll@arm.com \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=t.figa@samsung.com \ --cc=tomasz.figa@gmail.com \ /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: linkBe 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.