[U-Boot] [PATCH v1] mmc: sdhci: SDHCI controllers also need power

[Jaehoon Chung]

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 at chromium.org>
>>> wrote:
>>>> On 1 April 2017 at 07:11, Andy Shevchenko
>>>> <andriy.shevchenko at 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 at 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 at 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

>