obtaining a regulator from a phandle

[Thierry Reding]

* Thierry Reding wrote:
> * Stephen Warren wrote:
> > Thierry Reding wrote at Monday, March 05, 2012 8:22 AM:
> > > This all works well, except there seems to be no API to obtain a regulator
> > > from the DT phandle.
> > 
> > regulator_get(pcie_dev, "pex-clk") should work.
> 
> Ah, I see. That would call regulator_dev_lookup(), which would call
> of_get_regulator() which will lookup the pex-clk-supply property. I
> will give that a shot.

regulator_get(&pdev->dev, "pex-clk") worked as expected.

> > Of course, the PCIe host on Tegra isn't yet a platform device, so would
> > have to be converted.
> 
> I've already converted that. I was going to send the patch when I've tested
> that this works in a DT setup as well. So far I have only tested it on non-
> DT Harmony.

Adding DT support seems to be more complicated than I anticipated. Starting
from the platform driver that works on non-DT Harmony I added DT support to
the tps6586x driver in order to be able to use its regulators from the PCIe
driver (also extended with DT support). That worked great.

However, the PCIe controller needs another (fixed) regulator as VDD supply.
On Harmony (and the hardware that I use) this is GPIO#2 of the PMU (tps6586x)
so I added another regulator to the device tree which uses that GPIO and
passed it to the PCIe device node (vdd-supply property).

And this is precisely where things get ugly. Now there is a dependency
problem between the fixed regulator and the PMU which provides the GPIO. Both
the PMU and the fixed regulator are setup via subsys_initcall(), and the
regulator beats the PMU, resulting in the fixed regulator being unable to get
the GPIO because it hasn't been setup yet. So I remembered Grant's deferred
probing patch from yesterday and thought I'd try it out. This worked great,
and the fixed regulator was properly set up after all other devices had been
probed.

The PCIe driver now also needs deferred probing until the fixed regulator is
present, which also works as expected. But then the problems start. Since now
we're so far into the boot process that all __init{,data} is gone, therefore
pci_common_init() is no longer present, resulting in an ugly crash.

So the only way I see out of this is patch up everything so that PCI
initialization can actually be done after init memory is freed. This would
have the added benefit that the driver could actually be built as a module.

Does anyone see another (easier) way out of this?

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120306/6cc1c178/attachment.pgp>