Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
Hi Andy, On 19 April 2017 at 05:50, Andy Shevchenko wrote: > On Tue, 2017-04-18 at 18:12 -0600, Simon Glass wrote: >> Hi Andy, >> >> On 18 April 2017 at 08:45, Andy Shevchenko >> wrote: >> > On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote: >> > > Hi Andy, >> > > >> > > On 18 April 2017 at 08:29, Andy Shevchenko >> > > wrote: >> > > > On Fri, 2017-04-07 at 19:05 +0900, Jaehoon Chung wrote: >> > > > > Hi Andy, >> > > > > >> > > > > On 04/06/2017 07:58 PM, Andy Shevchenko wrote: >> > > > > > On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung > > > > > > msun >> > > > > > g.co >> > > > > > m> wrote: >> > > > > > > On 04/06/2017 06:46 PM, Andy Shevchenko wrote: >> > > > > > > > On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: >> > > > > > > > > On 04/06/2017 05:51 PM, Andy Shevchenko wrote: >> > > > > > > > > > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > > > > > > > > > > omiu >> > > > > > > > > > m.or >> > > > > > > > > > g> >> > > > > > > > > > wrote: >> > > > > > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko >> > > > > > > > > > > wrote: >> > > > > > > > > >> > > > > > > > > how about mmc_power_init() is called in mmc_probe()? >> > > > > > > > Yes, that's what I'm referring to. But the driver is >> > > > > > > > pure >> > > > > > > > SDHCI, >> > > > > > > > it >> > > > > > > > doesn't call mmc_probe() IIRC. >> > > > > > > >> > > > > > > After converting to DM, it might have the dependent to >> > > > > > > probing >> > > > > > > sequence. >> > > > > > > I'm not sure that u-boot has the priority for probing. >> > > > > > > maybe >> > > > > > > not... >> > > > > > > >> > > > > > > hmm..need to consider this patch..but i will think about >> > > > > > > more >> > > > > > > generic solution.. >> > > > > > >> > > > > > It would be nice to have a generic solution indeed. >> > > > > >> > > > > Just thinking about below..? >> > > > > >> > > > > vcc_sd: sdmmc-regulator { >> > > > > ... >> > > > > regulator-boot-on; >> > > > > or >> > > > > regulator-always-on; >> > > > > ... >> > > > > >> > > > > }; >> > > > > >> > > > > It should be always enabled.. >> > > > >> > > > Sorry, but no. It's not a regulator. >> > > > >> > > > If you would like to know details, the 2 bits in PMU registers >> > > > basically >> > > > represent clock gate and reset signal per IP which PMU controls. >> > > > >> > > > P.S. Hardware might have a common regulator per power island >> > > > which >> > > > is >> > > > automatically latches the power down if all devices on the >> > > > island >> > > > are on >> > > > D3hot. But it's not controlled by software. >> > > >> > > You have a few options: >> > > >> > > - Add a regulator/pmic driver for the PMU >> > >> > I dunno how many times should I repeat that it is *not* a PMIC at >> > all! >> > >> > PMIC is a separate *external* IC which is connected to Atom SoC. And >> > it >> > has nothing to do with PMU (on software level). >> >> That doesn't really matter though. The point is how it is modeled in >> U-Boot. > > Hardware matters. Software (drivers) represents whatever hardware design > is underneath. This is how Linux kernel at least being designed. Does U- > Boot follow the same paradigm? I'm not sure what you are getting at. Is there a call to board_mmc_power_init() in the middle of the Linux MMC stack? It breaks the driver model. While U-Boot's driver model is perhaps a bit stricter than Linux, on this point they surely agree. > >> > >> > > - Add a reset driver to handle the reset and perhaps a clock >> > > driver to >> > > handle the clock gate, then handle this in your driver >> > >> > No, I disclosed details just for your understanding that it's not a >> > regulator. On the other hand it's 1:1 mapping to D0/D3hot in PCI, >> > and >> > bits can't be switched separately by specification. >> > >> > TBH I even don't know which one is which. >> > >> > > You can subclass sdhci.c and adjust it as you need it. >> > > >> > > > >> > > > So, please consider my initial approach. >> > > >> > > We should use DM rather than custom hooks. >> > >> > Can anyone answer to a simple question why MMC code *has* been >> > calling >> > such hook and you strongly object to do the same / similar for >> > SDHCI? >> >> Can you point me to the mmc function you are referring to? > > drivers/mmc/mmc.c: > > -> (mmc-uclass.c) mmc_blk_probe() > -> mmc_init() > -> mmc_start_init() > -> mmc_power_init() >-> board_mmc_power_init() If you look at mmc_power_init() you can see it already has the code to enable a regulator. This is what you should be using. I've just sent a patch to clarify that: http://patchwork.ozlabs.org/patch/753851/ An alternative if you like is to enable the power in your board code before you even get to your MMC driver. > >> > > If this doesn't make sense >> > >> > It does not. >> > >> > > please let me know how I can help expound on it. >> > >> > Please, elaborate how pure SDHCI drivers are so different to MMC in >> > init >> > stage and w
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Tue, 2017-04-18 at 18:12 -0600, Simon Glass wrote: > Hi Andy, > > On 18 April 2017 at 08:45, Andy Shevchenko > wrote: > > On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote: > > > Hi Andy, > > > > > > On 18 April 2017 at 08:29, Andy Shevchenko > > > wrote: > > > > On Fri, 2017-04-07 at 19:05 +0900, Jaehoon Chung wrote: > > > > > Hi Andy, > > > > > > > > > > On 04/06/2017 07:58 PM, Andy Shevchenko wrote: > > > > > > On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung > > > > > msun > > > > > > g.co > > > > > > m> wrote: > > > > > > > On 04/06/2017 06:46 PM, Andy Shevchenko wrote: > > > > > > > > On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: > > > > > > > > > On 04/06/2017 05:51 PM, Andy Shevchenko wrote: > > > > > > > > > > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > > > > > > > > > omiu > > > > > > > > > > m.or > > > > > > > > > > g> > > > > > > > > > > wrote: > > > > > > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > how about mmc_power_init() is called in mmc_probe()? > > > > > > > > Yes, that's what I'm referring to. But the driver is > > > > > > > > pure > > > > > > > > SDHCI, > > > > > > > > it > > > > > > > > doesn't call mmc_probe() IIRC. > > > > > > > > > > > > > > After converting to DM, it might have the dependent to > > > > > > > probing > > > > > > > sequence. > > > > > > > I'm not sure that u-boot has the priority for probing. > > > > > > > maybe > > > > > > > not... > > > > > > > > > > > > > > hmm..need to consider this patch..but i will think about > > > > > > > more > > > > > > > generic solution.. > > > > > > > > > > > > It would be nice to have a generic solution indeed. > > > > > > > > > > Just thinking about below..? > > > > > > > > > > vcc_sd: sdmmc-regulator { > > > > > ... > > > > > regulator-boot-on; > > > > > or > > > > > regulator-always-on; > > > > > ... > > > > > > > > > > }; > > > > > > > > > > It should be always enabled.. > > > > > > > > Sorry, but no. It's not a regulator. > > > > > > > > If you would like to know details, the 2 bits in PMU registers > > > > basically > > > > represent clock gate and reset signal per IP which PMU controls. > > > > > > > > P.S. Hardware might have a common regulator per power island > > > > which > > > > is > > > > automatically latches the power down if all devices on the > > > > island > > > > are on > > > > D3hot. But it's not controlled by software. > > > > > > You have a few options: > > > > > > - Add a regulator/pmic driver for the PMU > > > > I dunno how many times should I repeat that it is *not* a PMIC at > > all! > > > > PMIC is a separate *external* IC which is connected to Atom SoC. And > > it > > has nothing to do with PMU (on software level). > > That doesn't really matter though. The point is how it is modeled in > U-Boot. Hardware matters. Software (drivers) represents whatever hardware design is underneath. This is how Linux kernel at least being designed. Does U- Boot follow the same paradigm? > > > > > - Add a reset driver to handle the reset and perhaps a clock > > > driver to > > > handle the clock gate, then handle this in your driver > > > > No, I disclosed details just for your understanding that it's not a > > regulator. On the other hand it's 1:1 mapping to D0/D3hot in PCI, > > and > > bits can't be switched separately by specification. > > > > TBH I even don't know which one is which. > > > > > You can subclass sdhci.c and adjust it as you need it. > > > > > > > > > > > So, please consider my initial approach. > > > > > > We should use DM rather than custom hooks. > > > > Can anyone answer to a simple question why MMC code *has* been > > calling > > such hook and you strongly object to do the same / similar for > > SDHCI? > > Can you point me to the mmc function you are referring to? drivers/mmc/mmc.c: -> (mmc-uclass.c) mmc_blk_probe() -> mmc_init() -> mmc_start_init() -> mmc_power_init() -> board_mmc_power_init() > > > If this doesn't make sense > > > > It does not. > > > > > please let me know how I can help expound on it. > > > > Please, elaborate how pure SDHCI drivers are so different to MMC in > > init > > stage and why, but please don't offer regulators. > > It's just that we cannot call a board hook function from DM. World is not ideal, and for me is clear that DM is not ideal either. > That's > the way things used to work, but with DM we need to have things in the > driver. > > I'm sorry if you're finding this frustrating, but I do want to > understand this. While it seems like a minor point it actually is a > key design feature of DM. I understand your point. And I am all ears to implement the best of possible solutions (with current U-Boot design), OTOH I don't like any idea of faking in software something that is not present on real platform (like doing weird PMIC or regulators for PMU which is not either of them). Please, understand
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
Hi Andy, On 18 April 2017 at 08:45, Andy Shevchenko wrote: > On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote: >> Hi Andy, >> >> On 18 April 2017 at 08:29, Andy Shevchenko >> wrote: >> > On Fri, 2017-04-07 at 19:05 +0900, Jaehoon Chung wrote: >> > > Hi Andy, >> > > >> > > On 04/06/2017 07:58 PM, Andy Shevchenko wrote: >> > > > On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung > > > > g.co >> > > > m> wrote: >> > > > > On 04/06/2017 06:46 PM, Andy Shevchenko wrote: >> > > > > > On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: >> > > > > > > On 04/06/2017 05:51 PM, Andy Shevchenko wrote: >> > > > > > > > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > > > > > > > > m.or >> > > > > > > > g> >> > > > > > > > wrote: >> > > > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko >> > > > > > > > > wrote: >> > > > > > > >> > > > > > > how about mmc_power_init() is called in mmc_probe()? >> > > > > > > >> > > > > > Yes, that's what I'm referring to. But the driver is pure >> > > > > > SDHCI, >> > > > > > it >> > > > > > doesn't call mmc_probe() IIRC. >> > > > > >> > > > > After converting to DM, it might have the dependent to probing >> > > > > sequence. >> > > > > I'm not sure that u-boot has the priority for probing. maybe >> > > > > not... >> > > > > >> > > > > hmm..need to consider this patch..but i will think about more >> > > > > generic solution.. >> > > > >> > > > It would be nice to have a generic solution indeed. >> > > >> > > Just thinking about below..? >> > > >> > > vcc_sd: sdmmc-regulator { >> > > ... >> > > regulator-boot-on; >> > > or >> > > regulator-always-on; >> > > ... >> > > >> > > }; >> > > >> > > It should be always enabled.. >> > >> > Sorry, but no. It's not a regulator. >> > >> > If you would like to know details, the 2 bits in PMU registers >> > basically >> > represent clock gate and reset signal per IP which PMU controls. >> > >> > P.S. Hardware might have a common regulator per power island which >> > is >> > automatically latches the power down if all devices on the island >> > are on >> > D3hot. But it's not controlled by software. >> >> You have a few options: >> >> - Add a regulator/pmic driver for the PMU > > I dunno how many times should I repeat that it is *not* a PMIC at all! > > PMIC is a separate *external* IC which is connected to Atom SoC. And it > has nothing to do with PMU (on software level). That doesn't really matter though. The point is how it is modeled in U-Boot. > >> - Add a reset driver to handle the reset and perhaps a clock driver to >> handle the clock gate, then handle this in your driver > > No, I disclosed details just for your understanding that it's not a > regulator. On the other hand it's 1:1 mapping to D0/D3hot in PCI, and > bits can't be switched separately by specification. > > TBH I even don't know which one is which. > >> You can subclass sdhci.c and adjust it as you need it. >> >> > >> > So, please consider my initial approach. >> >> We should use DM rather than custom hooks. > > Can anyone answer to a simple question why MMC code *has* been calling > such hook and you strongly object to do the same / similar for SDHCI? Can you point me to the mmc function you are referring to? > >> If this doesn't make sense > > It does not. > >> please let me know how I can help expound on it. > > Please, elaborate how pure SDHCI drivers are so different to MMC in init > stage and why, but please don't offer regulators. It's just that we cannot call a board hook function from DM. That's the way things used to work, but with DM we need to have things in the driver. I'm sorry if you're finding this frustrating, but I do want to understand this. While it seems like a minor point it actually is a key design feature of DM. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote: > Hi Andy, > > On 18 April 2017 at 08:29, Andy Shevchenko > wrote: > > On Fri, 2017-04-07 at 19:05 +0900, Jaehoon Chung wrote: > > > Hi Andy, > > > > > > On 04/06/2017 07:58 PM, Andy Shevchenko wrote: > > > > On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung > > > g.co > > > > m> wrote: > > > > > On 04/06/2017 06:46 PM, Andy Shevchenko wrote: > > > > > > On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: > > > > > > > On 04/06/2017 05:51 PM, Andy Shevchenko wrote: > > > > > > > > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > > > > > > > m.or > > > > > > > > g> > > > > > > > > wrote: > > > > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > > > > > > > wrote: > > > > > > > > > > > > > > how about mmc_power_init() is called in mmc_probe()? > > > > > > > > > > > > Yes, that's what I'm referring to. But the driver is pure > > > > > > SDHCI, > > > > > > it > > > > > > doesn't call mmc_probe() IIRC. > > > > > > > > > > After converting to DM, it might have the dependent to probing > > > > > sequence. > > > > > I'm not sure that u-boot has the priority for probing. maybe > > > > > not... > > > > > > > > > > hmm..need to consider this patch..but i will think about more > > > > > generic solution.. > > > > > > > > It would be nice to have a generic solution indeed. > > > > > > Just thinking about below..? > > > > > > vcc_sd: sdmmc-regulator { > > > ... > > > regulator-boot-on; > > > or > > > regulator-always-on; > > > ... > > > > > > }; > > > > > > It should be always enabled.. > > > > Sorry, but no. It's not a regulator. > > > > If you would like to know details, the 2 bits in PMU registers > > basically > > represent clock gate and reset signal per IP which PMU controls. > > > > P.S. Hardware might have a common regulator per power island which > > is > > automatically latches the power down if all devices on the island > > are on > > D3hot. But it's not controlled by software. > > You have a few options: > > - Add a regulator/pmic driver for the PMU I dunno how many times should I repeat that it is *not* a PMIC at all! PMIC is a separate *external* IC which is connected to Atom SoC. And it has nothing to do with PMU (on software level). > - Add a reset driver to handle the reset and perhaps a clock driver to > handle the clock gate, then handle this in your driver No, I disclosed details just for your understanding that it's not a regulator. On the other hand it's 1:1 mapping to D0/D3hot in PCI, and bits can't be switched separately by specification. TBH I even don't know which one is which. > You can subclass sdhci.c and adjust it as you need it. > > > > > So, please consider my initial approach. > > We should use DM rather than custom hooks. Can anyone answer to a simple question why MMC code *has* been calling such hook and you strongly object to do the same / similar for SDHCI? > If this doesn't make sense It does not. > please let me know how I can help expound on it. Please, elaborate how pure SDHCI drivers are so different to MMC in init stage and why, but please don't offer regulators. -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
Hi Andy, On 18 April 2017 at 08:29, Andy Shevchenko wrote: > On Fri, 2017-04-07 at 19:05 +0900, Jaehoon Chung wrote: >> Hi Andy, >> >> On 04/06/2017 07:58 PM, Andy Shevchenko wrote: >> > On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung > > m> wrote: >> > > On 04/06/2017 06:46 PM, Andy Shevchenko wrote: >> > > > On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: >> > > > > On 04/06/2017 05:51 PM, Andy Shevchenko wrote: >> > > > > > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > > > > > > g> >> > > > > > wrote: >> > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko >> > > > > > > wrote: >> > > > > how about mmc_power_init() is called in mmc_probe()? >> > > > >> > > > Yes, that's what I'm referring to. But the driver is pure SDHCI, >> > > > it >> > > > doesn't call mmc_probe() IIRC. >> > > >> > > After converting to DM, it might have the dependent to probing >> > > sequence. >> > > I'm not sure that u-boot has the priority for probing. maybe >> > > not... >> > > >> > > hmm..need to consider this patch..but i will think about more >> > > generic solution.. >> > >> > It would be nice to have a generic solution indeed. >> >> Just thinking about below..? >> >> vcc_sd: sdmmc-regulator { >> ... >> regulator-boot-on; >> or >> regulator-always-on; >> ... >> >> }; >> >> It should be always enabled.. > > Sorry, but no. It's not a regulator. > > If you would like to know details, the 2 bits in PMU registers basically > represent clock gate and reset signal per IP which PMU controls. > > P.S. Hardware might have a common regulator per power island which is > automatically latches the power down if all devices on the island are on > D3hot. But it's not controlled by software. You have a few options: - Add a regulator/pmic driver for the PMU - Add a reset driver to handle the reset and perhaps a clock driver to handle the clock gate, then handle this in your driver You can subclass sdhci.c and adjust it as you need it. > > So, please consider my initial approach. We should use DM rather than custom hooks. If this doesn't make sense please let me know how I can help expound on it. > > This patch holds Edison enabling... Then let's get it figured out! > > -- > Andy Shevchenko > Intel Finland Oy Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Fri, 2017-04-07 at 19:05 +0900, Jaehoon Chung wrote: > Hi Andy, > > On 04/06/2017 07:58 PM, Andy Shevchenko wrote: > > On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung > m> wrote: > > > On 04/06/2017 06:46 PM, Andy Shevchenko wrote: > > > > On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: > > > > > On 04/06/2017 05:51 PM, Andy Shevchenko wrote: > > > > > > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > > > > > g> > > > > > > wrote: > > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > > > > > wrote: > > > > > how about mmc_power_init() is called in mmc_probe()? > > > > > > > > Yes, that's what I'm referring to. But the driver is pure SDHCI, > > > > it > > > > doesn't call mmc_probe() IIRC. > > > > > > After converting to DM, it might have the dependent to probing > > > sequence. > > > I'm not sure that u-boot has the priority for probing. maybe > > > not... > > > > > > hmm..need to consider this patch..but i will think about more > > > generic solution.. > > > > It would be nice to have a generic solution indeed. > > Just thinking about below..? > > vcc_sd: sdmmc-regulator { > ... > regulator-boot-on; > or > regulator-always-on; > ... > > }; > > It should be always enabled.. Sorry, but no. It's not a regulator. If you would like to know details, the 2 bits in PMU registers basically represent clock gate and reset signal per IP which PMU controls. P.S. Hardware might have a common regulator per power island which is automatically latches the power down if all devices on the island are on D3hot. But it's not controlled by software. So, please consider my initial approach. This patch holds Edison enabling... -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
Hi Andy, On 04/06/2017 07:58 PM, Andy Shevchenko wrote: > On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung wrote: >> On 04/06/2017 06:46 PM, Andy Shevchenko wrote: >>> On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: On 04/06/2017 05:51 PM, Andy Shevchenko wrote: > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > wrote: >> On 1 April 2017 at 07:11, Andy Shevchenko >> wrote: > how about mmc_power_init() is called in mmc_probe()? >>> >>> Yes, that's what I'm referring to. But the driver is pure SDHCI, it >>> doesn't call mmc_probe() IIRC. >> >> After converting to DM, it might have the dependent to probing sequence. >> I'm not sure that u-boot has the priority for probing. maybe not... >> >> hmm..need to consider this patch..but i will think about more generic >> solution.. > > It would be nice to have a generic solution indeed. Just thinking about below..? vcc_sd: sdmmc-regulator { ... regulator-boot-on; or regulator-always-on; ... }; It should be always enabled.. Best Regards, Jaehoon Chung > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung wrote: > On 04/06/2017 06:46 PM, Andy Shevchenko wrote: >> On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: >>> On 04/06/2017 05:51 PM, Andy Shevchenko wrote: On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass wrote: > On 1 April 2017 at 07:11, Andy Shevchenko > wrote: >>> how about mmc_power_init() is called in mmc_probe()? >> >> Yes, that's what I'm referring to. But the driver is pure SDHCI, it >> doesn't call mmc_probe() IIRC. > > After converting to DM, it might have the dependent to probing sequence. > I'm not sure that u-boot has the priority for probing. maybe not... > > hmm..need to consider this patch..but i will think about more generic > solution.. It would be nice to have a generic solution indeed. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On 04/06/2017 06:46 PM, Andy Shevchenko wrote: > On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: >> On 04/06/2017 05:51 PM, Andy Shevchenko wrote: >>> On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass >>> wrote: On 1 April 2017 at 07:11, Andy Shevchenko wrote: > On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote: >> On 20 March 2017 at 06:51, Andy Shevchenko >> wrote: >>> On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: On 15 March 2017 at 12:25, Andy Shevchenko wrote: > + board_mmc_power_init(); You should be using driver model for this (CONFIG_DM_MMC*). >>> >>> I didn't get this part. It's used by the driver >>> (tangier_sdhci) as >>> far >>> as I understand. > Oh, we are talking about host controller's power management > which is > done using PMU (power management unit) inside SoC. It's *not* a > power > regulator. > > Above is clearly about card power management, which we also have > (in > case of Wi-Fi), but it's not applicable for eMMC soldered on the > module. Still if the eMMC is soldered on, it needs power, right? What is the distinction? >>> >>> It's irrelevant to this patch and discussion. >>> In any case we cannot call board code from the driver with DM - it's just not how things work. So can you init it in your board_init() code perhaps, if you can't use a power driver? >>> >>> I didn't get this either. >>> >>> It means that PMU driver should *not* go with DM model then or what? >>> or do this in the board code. >>> >>> How? It's already board code that powers on the controller. >>> If you >>> look >>> at mmc_init() it does this. SDHCI on the other hand doesn't >>> which is >>> for >>> my opinion is a bug. Otherwise why is the difference between >>> initialization sequence of MMC and SHDCI controllers? >> >> There should not really be a different I think, except that >> with >> driver model we want to use drivers for power rather than >> hard-coding >> things in custom code. > > I totally agree with this, though since we have no clear PCI > implementation on that board (*) we can't have good described > PCI power > management for it. > > (*) It's called "fake PCI" meaning it mimics PCI programming > interface > while being not 100% compatible with PCI specification on > hardware and > firmware levels. > > So, for now I have been seeing no alternatives than my initial > approach, > though I'm all ears for better solution. Well you can create a regulator driver which has a single regulator to handle whatever needs doing to enable MMC power. >>> >>> No. It looks like you are mixing two power controls: card itself and >>> host controller. They are using quite different mechanisms to be >>> powered on. >>> We are talking here about *host* controller power flow. >>> >>> And still there is no clarification why MMC flow calls board code >>> and >>> on the other hand you made an objectiion to do the same for SDHCI. >>> >>> I still do not see better solution as mine initial one, otherwise >>> above question should be clarified first. >> >> how about mmc_power_init() is called in mmc_probe()? > > Yes, that's what I'm referring to. But the driver is pure SDHCI, it > doesn't call mmc_probe() IIRC. After converting to DM, it might have the dependent to probing sequence. I'm not sure that u-boot has the priority for probing. maybe not... hmm..need to consider this patch..but i will think about more generic solution.. Best Regards, Jaehoon Chung > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Thu, 2017-04-06 at 18:24 +0900, Jaehoon Chung wrote: > On 04/06/2017 05:51 PM, Andy Shevchenko wrote: > > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass > > wrote: > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > wrote: > > > > On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote: > > > > > On 20 March 2017 at 06:51, Andy Shevchenko > > > > > wrote: > > > > > > On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: > > > > > > > On 15 March 2017 at 12:25, Andy Shevchenko > > > > > > > wrote: > > > > > > > > + board_mmc_power_init(); > > > > > > > You should be using driver model for this > > > > > > > (CONFIG_DM_MMC*). > > > > > > > > > > > > I didn't get this part. It's used by the driver > > > > > > (tangier_sdhci) as > > > > > > far > > > > > > as I understand. > > > > Oh, we are talking about host controller's power management > > > > which is > > > > done using PMU (power management unit) inside SoC. It's *not* a > > > > power > > > > regulator. > > > > > > > > Above is clearly about card power management, which we also have > > > > (in > > > > case of Wi-Fi), but it's not applicable for eMMC soldered on the > > > > module. > > > > > > Still if the eMMC is soldered on, it needs power, right? What is > > > the > > > distinction? > > > > It's irrelevant to this patch and discussion. > > > > > In any case we cannot call board code from the driver with DM - > > > it's > > > just not how things work. So can you init it in your board_init() > > > code > > > perhaps, if you can't use a power driver? > > > > I didn't get this either. > > > > It means that PMU driver should *not* go with DM model then or what? > > > > > > > > > or do this in > > > > > > > the board code. > > > > > > > > > > > > How? It's already board code that powers on the controller. > > > > > > If you > > > > > > look > > > > > > at mmc_init() it does this. SDHCI on the other hand doesn't > > > > > > which is > > > > > > for > > > > > > my opinion is a bug. Otherwise why is the difference between > > > > > > initialization sequence of MMC and SHDCI controllers? > > > > > > > > > > There should not really be a different I think, except that > > > > > with > > > > > driver model we want to use drivers for power rather than > > > > > hard-coding > > > > > things in custom code. > > > > > > > > I totally agree with this, though since we have no clear PCI > > > > implementation on that board (*) we can't have good described > > > > PCI power > > > > management for it. > > > > > > > > (*) It's called "fake PCI" meaning it mimics PCI programming > > > > interface > > > > while being not 100% compatible with PCI specification on > > > > hardware and > > > > firmware levels. > > > > > > > > So, for now I have been seeing no alternatives than my initial > > > > approach, > > > > though I'm all ears for better solution. > > > Well you can create a regulator driver which has a single > > > regulator to > > > handle whatever needs doing to enable MMC power. > > > > No. It looks like you are mixing two power controls: card itself and > > host controller. They are using quite different mechanisms to be > > powered on. > > We are talking here about *host* controller power flow. > > > > And still there is no clarification why MMC flow calls board code > > and > > on the other hand you made an objectiion to do the same for SDHCI. > > > > I still do not see better solution as mine initial one, otherwise > > above question should be clarified first. > > how about mmc_power_init() is called in mmc_probe()? Yes, that's what I'm referring to. But the driver is pure SDHCI, it doesn't call mmc_probe() IIRC. -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On 04/06/2017 05:51 PM, Andy Shevchenko wrote: > On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass wrote: >> On 1 April 2017 at 07:11, Andy Shevchenko >> wrote: >>> On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote: On 20 March 2017 at 06:51, Andy Shevchenko wrote: > On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: >> On 15 March 2017 at 12:25, Andy Shevchenko >> wrote: > >>> + board_mmc_power_init(); > >> You should be using driver model for this (CONFIG_DM_MMC*). > > I didn't get this part. It's used by the driver (tangier_sdhci) as > far > as I understand. > >>> Oh, we are talking about host controller's power management which is >>> done using PMU (power management unit) inside SoC. It's *not* a power >>> regulator. >>> >>> Above is clearly about card power management, which we also have (in >>> case of Wi-Fi), but it's not applicable for eMMC soldered on the module. >> >> Still if the eMMC is soldered on, it needs power, right? What is the >> distinction? > > It's irrelevant to this patch and discussion. > >> In any case we cannot call board code from the driver with DM - it's >> just not how things work. So can you init it in your board_init() code >> perhaps, if you can't use a power driver? > > I didn't get this either. > > It means that PMU driver should *not* go with DM model then or what? > >> or do this in >> the board code. > > How? It's already board code that powers on the controller. If you > look > at mmc_init() it does this. SDHCI on the other hand doesn't which is > for > my opinion is a bug. Otherwise why is the difference between > initialization sequence of MMC and SHDCI controllers? There should not really be a different I think, except that with driver model we want to use drivers for power rather than hard-coding things in custom code. >>> >>> I totally agree with this, though since we have no clear PCI >>> implementation on that board (*) we can't have good described PCI power >>> management for it. >>> >>> (*) It's called "fake PCI" meaning it mimics PCI programming interface >>> while being not 100% compatible with PCI specification on hardware and >>> firmware levels. >>> >>> So, for now I have been seeing no alternatives than my initial approach, >>> though I'm all ears for better solution. >> > >> Well you can create a regulator driver which has a single regulator to >> handle whatever needs doing to enable MMC power. > > No. It looks like you are mixing two power controls: card itself and > host controller. They are using quite different mechanisms to be > powered on. > We are talking here about *host* controller power flow. > > And still there is no clarification why MMC flow calls board code and > on the other hand you made an objectiion to do the same for SDHCI. > > I still do not see better solution as mine initial one, otherwise > above question should be clarified first. how about mmc_power_init() is called in mmc_probe()? > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass wrote: > On 1 April 2017 at 07:11, Andy Shevchenko > wrote: >> On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote: >>> On 20 March 2017 at 06:51, Andy Shevchenko >>> wrote: >>> > On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: >>> > > On 15 March 2017 at 12:25, Andy Shevchenko >>> > > wrote: >>> > > > + board_mmc_power_init(); >>> > > You should be using driver model for this (CONFIG_DM_MMC*). >>> > >>> > I didn't get this part. It's used by the driver (tangier_sdhci) as >>> > far >>> > as I understand. >> Oh, we are talking about host controller's power management which is >> done using PMU (power management unit) inside SoC. It's *not* a power >> regulator. >> >> Above is clearly about card power management, which we also have (in >> case of Wi-Fi), but it's not applicable for eMMC soldered on the module. > > Still if the eMMC is soldered on, it needs power, right? What is the > distinction? It's irrelevant to this patch and discussion. > In any case we cannot call board code from the driver with DM - it's > just not how things work. So can you init it in your board_init() code > perhaps, if you can't use a power driver? I didn't get this either. It means that PMU driver should *not* go with DM model then or what? >>> > > or do this in >>> > > the board code. >>> > >>> > How? It's already board code that powers on the controller. If you >>> > look >>> > at mmc_init() it does this. SDHCI on the other hand doesn't which is >>> > for >>> > my opinion is a bug. Otherwise why is the difference between >>> > initialization sequence of MMC and SHDCI controllers? >>> >>> There should not really be a different I think, except that with >>> driver model we want to use drivers for power rather than hard-coding >>> things in custom code. >> >> I totally agree with this, though since we have no clear PCI >> implementation on that board (*) we can't have good described PCI power >> management for it. >> >> (*) It's called "fake PCI" meaning it mimics PCI programming interface >> while being not 100% compatible with PCI specification on hardware and >> firmware levels. >> >> So, for now I have been seeing no alternatives than my initial approach, >> though I'm all ears for better solution. > > Well you can create a regulator driver which has a single regulator to > handle whatever needs doing to enable MMC power. No. It looks like you are mixing two power controls: card itself and host controller. They are using quite different mechanisms to be powered on. We are talking here about *host* controller power flow. And still there is no clarification why MMC flow calls board code and on the other hand you made an objectiion to do the same for SDHCI. I still do not see better solution as mine initial one, otherwise above question should be clarified first. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
Hi Andy, On 1 April 2017 at 07:11, Andy Shevchenko wrote: > On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote: >> Hi Andy, >> >> On 20 March 2017 at 06:51, Andy Shevchenko >> wrote: >> > On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: >> > > Hi Andy, >> > > >> > > On 15 March 2017 at 12:25, Andy Shevchenko >> > > wrote: > >> > > > On some systems SDHCI controllers may be powered off and it's >> > > > required >> > > > to bring them on before accessing. >> > > > >> > > > SDHCI generic driver currently lacks any mean of doing it. Call >> > > > the >> > > > same >> > > > board_power_mmc_init() at sdhci_init() stage. >> > > > >> > > > Signed-off-by: Andy Shevchenko > > > > m> >> > > > --- >> > > > drivers/mmc/sdhci.c | 2 ++ >> > > > 1 file changed, 2 insertions(+) >> > > > >> > > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c >> > > > index 93cefd89cd..54a7e379ff 100644 >> > > > --- a/drivers/mmc/sdhci.c >> > > > +++ b/drivers/mmc/sdhci.c >> > > > @@ -469,6 +469,8 @@ static int sdhci_init(struct mmc *mmc) >> > > > { >> > > > struct sdhci_host *host = mmc->priv; >> > > > >> > > > + board_mmc_power_init(); >> > > >> > > You should be using driver model for this (CONFIG_DM_MMC*). >> > >> > I didn't get this part. It's used by the driver (tangier_sdhci) as >> > far >> > as I understand. >> > >> > > So either >> > > get the power supply from the device tree and enable it, >> > >> > Any example? >> >> Well in mmc_power_init() there is: >> >> ret = device_get_supply_regulator(mmc->dev, "vmmc-supply", >> &vmmc_supply); >> >> or say you have a node like this (from firefly-rk3288): >> >> vcc_sd: sdmmc-regulator { >> compatible = "regulator-fixed"; >> gpio = <&gpio7 11 GPIO_ACTIVE_LOW>; >> pinctrl-names = "default"; >> pinctrl-0 = <&sdmmc_pwr>; >> regulator-name = "vcc_sd"; >> regulator-min-microvolt = <330>; >> regulator-max-microvolt = <330>; >> startup-delay-us = <10>; >> vin-supply = <&vcc_io>; >> }; >> >> Then you can use regulator_get_by_platname("vcc_sd"... > > Oh, we are talking about host controller's power management which is > done using PMU (power management unit) inside SoC. It's *not* a power > regulator. > > Above is clearly about card power management, which we also have (in > case of Wi-Fi), but it's not applicable for eMMC soldered on the module. Still if the eMMC is soldered on, it needs power, right? What is the distinction? In any case we cannot call board code from the driver with DM - it's just not how things work. So can you init it in your board_init() code perhaps, if you can't use a power driver? > >> > > or do this in >> > > the board code. >> > >> > How? It's already board code that powers on the controller. If you >> > look >> > at mmc_init() it does this. SDHCI on the other hand doesn't which is >> > for >> > my opinion is a bug. Otherwise why is the difference between >> > initialization sequence of MMC and SHDCI controllers? >> >> There should not really be a different I think, except that with >> driver model we want to use drivers for power rather than hard-coding >> things in custom code. > > I totally agree with this, though since we have no clear PCI > implementation on that board (*) we can't have good described PCI power > management for it. > > (*) It's called "fake PCI" meaning it mimics PCI programming interface > while being not 100% compatible with PCI specification on hardware and > firmware levels. > > So, for now I have been seeing no alternatives than my initial approach, > though I'm all ears for better solution. Well you can create a regulator driver which has a single regulator to handle whatever needs doing to enable MMC power. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote: > Hi Andy, > > On 20 March 2017 at 06:51, Andy Shevchenko > wrote: > > On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: > > > Hi Andy, > > > > > > On 15 March 2017 at 12:25, Andy Shevchenko > > > wrote: > > > > On some systems SDHCI controllers may be powered off and it's > > > > required > > > > to bring them on before accessing. > > > > > > > > SDHCI generic driver currently lacks any mean of doing it. Call > > > > the > > > > same > > > > board_power_mmc_init() at sdhci_init() stage. > > > > > > > > Signed-off-by: Andy Shevchenko > > > m> > > > > --- > > > > drivers/mmc/sdhci.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c > > > > index 93cefd89cd..54a7e379ff 100644 > > > > --- a/drivers/mmc/sdhci.c > > > > +++ b/drivers/mmc/sdhci.c > > > > @@ -469,6 +469,8 @@ static int sdhci_init(struct mmc *mmc) > > > > { > > > > struct sdhci_host *host = mmc->priv; > > > > > > > > + board_mmc_power_init(); > > > > > > You should be using driver model for this (CONFIG_DM_MMC*). > > > > I didn't get this part. It's used by the driver (tangier_sdhci) as > > far > > as I understand. > > > > > So either > > > get the power supply from the device tree and enable it, > > > > Any example? > > Well in mmc_power_init() there is: > > ret = device_get_supply_regulator(mmc->dev, "vmmc-supply", > &vmmc_supply); > > or say you have a node like this (from firefly-rk3288): > > vcc_sd: sdmmc-regulator { > compatible = "regulator-fixed"; > gpio = <&gpio7 11 GPIO_ACTIVE_LOW>; > pinctrl-names = "default"; > pinctrl-0 = <&sdmmc_pwr>; > regulator-name = "vcc_sd"; > regulator-min-microvolt = <330>; > regulator-max-microvolt = <330>; > startup-delay-us = <10>; > vin-supply = <&vcc_io>; > }; > > Then you can use regulator_get_by_platname("vcc_sd"... Oh, we are talking about host controller's power management which is done using PMU (power management unit) inside SoC. It's *not* a power regulator. Above is clearly about card power management, which we also have (in case of Wi-Fi), but it's not applicable for eMMC soldered on the module. > > > or do this in > > > the board code. > > > > How? It's already board code that powers on the controller. If you > > look > > at mmc_init() it does this. SDHCI on the other hand doesn't which is > > for > > my opinion is a bug. Otherwise why is the difference between > > initialization sequence of MMC and SHDCI controllers? > > There should not really be a different I think, except that with > driver model we want to use drivers for power rather than hard-coding > things in custom code. I totally agree with this, though since we have no clear PCI implementation on that board (*) we can't have good described PCI power management for it. (*) It's called "fake PCI" meaning it mimics PCI programming interface while being not 100% compatible with PCI specification on hardware and firmware levels. So, for now I have been seeing no alternatives than my initial approach, though I'm all ears for better solution. -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
Hi Andy, On 20 March 2017 at 06:51, Andy Shevchenko wrote: > On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: >> Hi Andy, >> >> On 15 March 2017 at 12:25, Andy Shevchenko >> wrote: >> > On some systems SDHCI controllers may be powered off and it's >> > required >> > to bring them on before accessing. >> > >> > SDHCI generic driver currently lacks any mean of doing it. Call the >> > same >> > board_power_mmc_init() at sdhci_init() stage. >> > >> > Signed-off-by: Andy Shevchenko >> > --- >> > drivers/mmc/sdhci.c | 2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c >> > index 93cefd89cd..54a7e379ff 100644 >> > --- a/drivers/mmc/sdhci.c >> > +++ b/drivers/mmc/sdhci.c >> > @@ -469,6 +469,8 @@ static int sdhci_init(struct mmc *mmc) >> > { >> > struct sdhci_host *host = mmc->priv; >> > >> > + board_mmc_power_init(); >> >> You should be using driver model for this (CONFIG_DM_MMC*). > > I didn't get this part. It's used by the driver (tangier_sdhci) as far > as I understand. > >> So either >> get the power supply from the device tree and enable it, > > Any example? Well in mmc_power_init() there is: ret = device_get_supply_regulator(mmc->dev, "vmmc-supply", &vmmc_supply); or say you have a node like this (from firefly-rk3288): vcc_sd: sdmmc-regulator { compatible = "regulator-fixed"; gpio = <&gpio7 11 GPIO_ACTIVE_LOW>; pinctrl-names = "default"; pinctrl-0 = <&sdmmc_pwr>; regulator-name = "vcc_sd"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; startup-delay-us = <10>; vin-supply = <&vcc_io>; }; Then you can use regulator_get_by_platname("vcc_sd"... > >> or do this in >> the board code. > > How? It's already board code that powers on the controller. If you look > at mmc_init() it does this. SDHCI on the other hand doesn't which is for > my opinion is a bug. Otherwise why is the difference between > initialization sequence of MMC and SHDCI controllers? There should not really be a different I think, except that with driver model we want to use drivers for power rather than hard-coding things in custom code. > >> >> > + >> > sdhci_reset(host, SDHCI_RESET_ALL); >> > >> > if ((host->quirks & SDHCI_QUIRK_32BIT_DMA_ADDR) && >> > !aligned_buffer) { >> > -- >> > 2.11.0 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: > Hi Andy, > > On 15 March 2017 at 12:25, Andy Shevchenko > wrote: > > On some systems SDHCI controllers may be powered off and it's > > required > > to bring them on before accessing. > > > > SDHCI generic driver currently lacks any mean of doing it. Call the > > same > > board_power_mmc_init() at sdhci_init() stage. > > > > Signed-off-by: Andy Shevchenko > > --- > > drivers/mmc/sdhci.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c > > index 93cefd89cd..54a7e379ff 100644 > > --- a/drivers/mmc/sdhci.c > > +++ b/drivers/mmc/sdhci.c > > @@ -469,6 +469,8 @@ static int sdhci_init(struct mmc *mmc) > > { > > struct sdhci_host *host = mmc->priv; > > > > + board_mmc_power_init(); > > You should be using driver model for this (CONFIG_DM_MMC*). I didn't get this part. It's used by the driver (tangier_sdhci) as far as I understand. > So either > get the power supply from the device tree and enable it, Any example? > or do this in > the board code. How? It's already board code that powers on the controller. If you look at mmc_init() it does this. SDHCI on the other hand doesn't which is for my opinion is a bug. Otherwise why is the difference between initialization sequence of MMC and SHDCI controllers? > > > + > > sdhci_reset(host, SDHCI_RESET_ALL); > > > > if ((host->quirks & SDHCI_QUIRK_32BIT_DMA_ADDR) && > > !aligned_buffer) { > > -- > > 2.11.0 > > > > Regards, > Simon -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
Hi Andy, On 15 March 2017 at 12:25, Andy Shevchenko wrote: > On some systems SDHCI controllers may be powered off and it's required > to bring them on before accessing. > > SDHCI generic driver currently lacks any mean of doing it. Call the same > board_power_mmc_init() at sdhci_init() stage. > > Signed-off-by: Andy Shevchenko > --- > drivers/mmc/sdhci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c > index 93cefd89cd..54a7e379ff 100644 > --- a/drivers/mmc/sdhci.c > +++ b/drivers/mmc/sdhci.c > @@ -469,6 +469,8 @@ static int sdhci_init(struct mmc *mmc) > { > struct sdhci_host *host = mmc->priv; > > + board_mmc_power_init(); You should be using driver model for this (CONFIG_DM_MMC*). So either get the power supply from the device tree and enable it, or do this in the board code. > + > sdhci_reset(host, SDHCI_RESET_ALL); > > if ((host->quirks & SDHCI_QUIRK_32BIT_DMA_ADDR) && !aligned_buffer) { > -- > 2.11.0 > Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power
On some systems SDHCI controllers may be powered off and it's required to bring them on before accessing. SDHCI generic driver currently lacks any mean of doing it. Call the same board_power_mmc_init() at sdhci_init() stage. Signed-off-by: Andy Shevchenko --- drivers/mmc/sdhci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index 93cefd89cd..54a7e379ff 100644 --- a/drivers/mmc/sdhci.c +++ b/drivers/mmc/sdhci.c @@ -469,6 +469,8 @@ static int sdhci_init(struct mmc *mmc) { struct sdhci_host *host = mmc->priv; + board_mmc_power_init(); + sdhci_reset(host, SDHCI_RESET_ALL); if ((host->quirks & SDHCI_QUIRK_32BIT_DMA_ADDR) && !aligned_buffer) { -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot