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