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 <s...@chromium.org> >>> wrote: >>>> On 1 April 2017 at 07:11, Andy Shevchenko >>>> <andriy.shevche...@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.shevche...@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.shevche...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot