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

[Jaehoon Chung]

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()?

>