On Tue, 2017-04-18 at 08:33 -0600, Simon Glass wrote:
> Hi Andy,
>
> On 18 April 2017 at 08:29, Andy Shevchenko
> <andriy.shevche...@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@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@chromiu
> > > > > > > > m.or
> > > > > > > > g>
> > > > > > > > wrote:
> > > > > > > > > On 1 April 2017 at 07:11, Andy Shevchenko
> > > > > > > > > <andriy.shevche...@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.shevche...@linux.intel.com>
Intel Finland Oy
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
