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

[Simon Glass]

Hi Andy,

On 18 April 2017 at 08:45, Andy Shevchenko
<andriy.shevchenko at 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 at 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 at 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 at chromiu
>> > > > > > > > m.or
>> > > > > > > > g>
>> > > > > > > > wrote:
>> > > > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko
>> > > > > > > > > <andriy.shevchenko at 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