[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 andriy.shevchenko@linux.intel.com --- 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) {
Hi Andy,
On 15 March 2017 at 12:25, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 andriy.shevchenko@linux.intel.com
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
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote:
Hi Andy,
On 15 March 2017 at 12:25, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 andriy.shevchenko@linux.intel.com
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
Hi Andy,
On 20 March 2017 at 06:51, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote:
Hi Andy,
On 15 March 2017 at 12:25, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 andriy.shevchenko@linux.intel.com
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 = <3300000>; regulator-max-microvolt = <3300000>; startup-delay-us = <100000>; 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
On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote:
Hi Andy,
On 20 March 2017 at 06:51, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote:
Hi Andy,
On 15 March 2017 at 12:25, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 <andriy.shevchenko@linux.intel.co 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 = <3300000>; regulator-max-microvolt = <3300000>; startup-delay-us = <100000>; 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.
Hi Andy,
On 1 April 2017 at 07:11, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote:
Hi Andy,
On 20 March 2017 at 06:51, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote:
Hi Andy,
On 15 March 2017 at 12:25, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 <andriy.shevchenko@linux.intel.co 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 = <3300000>; regulator-max-microvolt = <3300000>; startup-delay-us = <100000>; 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
On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass sjg@chromium.org wrote:
On 1 April 2017 at 07:11, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote:
On 20 March 2017 at 06:51, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote:
On 15 March 2017 at 12:25, Andy Shevchenko andriy.shevchenko@linux.intel.com 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.
On 04/06/2017 05:51 PM, Andy Shevchenko wrote:
On Thu, Apr 6, 2017 at 6:44 AM, Simon Glass sjg@chromium.org wrote:
On 1 April 2017 at 07:11, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote:
On 20 March 2017 at 06:51, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote:
On 15 March 2017 at 12:25, Andy Shevchenko andriy.shevchenko@linux.intel.com 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()?
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 sjg@chromium.org wrote:
On 1 April 2017 at 07:11, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote:
On 20 March 2017 at 06:51, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: > On 15 March 2017 at 12:25, Andy Shevchenko > andriy.shevchenko@linux.intel.com 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.
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 sjg@chromium.org wrote:
On 1 April 2017 at 07:11, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Fri, 2017-03-31 at 22:24 -0600, Simon Glass wrote:
On 20 March 2017 at 06:51, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote: > On Sun, 2017-03-19 at 20:30 -0600, Simon Glass wrote: >> On 15 March 2017 at 12:25, Andy Shevchenko >> andriy.shevchenko@linux.intel.com 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
On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung jh80.chung@samsung.com 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 sjg@chromium.org wrote:
On 1 April 2017 at 07:11, Andy Shevchenko andriy.shevchenko@linux.intel.com 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.
Hi Andy,
On 04/06/2017 07:58 PM, Andy Shevchenko wrote:
On Thu, Apr 6, 2017 at 1:50 PM, Jaehoon Chung jh80.chung@samsung.com 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 sjg@chromium.org wrote:
On 1 April 2017 at 07:11, Andy Shevchenko andriy.shevchenko@linux.intel.com 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
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 <jh80.chung@samsung.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 <sjg@chromium.or g> wrote: > On 1 April 2017 at 07:11, Andy Shevchenko > andriy.shevchenko@linux.intel.com 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...
Hi Andy,
On 18 April 2017 at 08:29, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 <jh80.chung@samsung.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 <sjg@chromium.or > g> > wrote: > > On 1 April 2017 at 07:11, Andy Shevchenko > > andriy.shevchenko@linux.intel.com 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 andriy.shevchenko@linux.intel.com Intel Finland Oy
Regards, Simon
On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote:
Hi Andy,
On 18 April 2017 at 08:29, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 <jh80.chung@samsun 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 <sjg@chromiu > > m.or > > g> > > wrote: > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > andriy.shevchenko@linux.intel.com 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.
Hi Andy,
On 18 April 2017 at 08:45, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote:
Hi Andy,
On 18 April 2017 at 08:29, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 <jh80.chung@samsun 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 <sjg@chromiu > > > m.or > > > g> > > > wrote: > > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > > andriy.shevchenko@linux.intel.com 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
On Tue, 2017-04-18 at 18:12 -0600, Simon Glass wrote:
Hi Andy,
On 18 April 2017 at 08:45, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote:
Hi Andy,
On 18 April 2017 at 08:29, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 <jh80.chung@sa 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 <sjg@chr > > > > omiu > > > > m.or > > > > g> > > > > wrote: > > > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > > > andriy.shevchenko@linux.intel.com 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 my point as well.
The other option (not a good one from user experience) is to disable SD card slot in U-Boot completely.
Hi Andy,
On 19 April 2017 at 05:50, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Tue, 2017-04-18 at 18:12 -0600, Simon Glass wrote:
Hi Andy,
On 18 April 2017 at 08:45, Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote:
Hi Andy,
On 18 April 2017 at 08:29, Andy Shevchenko andriy.shevchenko@linux.intel.com 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 <jh80.chung@sa > 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 <sjg@chr > > > > > omiu > > > > > m.or > > > > > g> > > > > > wrote: > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko > > > > > > andriy.shevchenko@linux.intel.com 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 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.
Ideal in what sense?
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).
What exactly is it, then? My understanding is that it is a bit in the register that controls power and reset for the MMC controller. Is that right? In that case, with driver model, we would use a regulator and a reset. If you really don't want to do that, then you can put the code in your board init e.g. in board_early_init_r().
Please, understand my point as well.
The other option (not a good one from user experience) is to disable SD card slot in U-Boot completely.
You could start with that, and then enable it later once you have the rest of the support in if you like.
I'm sorry that I being so inflexible here. I can tell that you are frustrated. But so far I cannot see a compelling reason to break the driver model approach here. While some boards have challenges I have not seen any big issues with dealing with power and reset with REGULATOR and RESET drivers.
Regards, Simon
participants (4)
-
Andy Shevchenko -
Andy Shevchenko -
Jaehoon Chung -
Simon Glass