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