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

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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

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