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

[Andy Shevchenko]

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).

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

>  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.

-- 
Andy Shevchenko <andriy.shevchenko at linux.intel.com>
Intel Finland Oy