Hi,

On 05/23/2014 04:54 PM, Arend van Spriel wrote:

On 05/23/14 15:28, Hans de Goede wrote:

quoted

Hi,

On 05/23/2014 03:21 PM, Arend van Spriel wrote:

quoted

On 05/23/14 13:50, Hans de Goede wrote:

quoted

Hi,

On 05/23/2014 01:22 PM, Mark Brown wrote:

quoted

On Fri, May 23, 2014 at 11:13:44AM +0200, Hans de Goede wrote:

quoted

Thinking more about this, I would like to make one change to my
proposal, the mmc-core should only do power up of child-nodes if
they have a compatible of: "simple-sdio-powerup". This way
when we add something more complex, we can keep the simple powerup
code in the mmc core, keeping what we've already using this working
and the mmc core won't respond to the child nodes for more complex
devices, so it won't conflict with more complex power-up handling
handled by some other driver.

Would it not be better to have this be something in the driver struct
rather than in the device tree?  Putting a compatible in there would be
encoding details of the Linux implementation in the DT which doesn't
seem right especially since these are details we're thinking of changing
later on.

The compatible is not a Linux specific thing, it is a marking saying
that something needs to take care of enabling the clks (and whatever
else we will make part of the binding for this compatible), before
scanning the mmc bus.

quoted

Something like have the driver set flags saying if it wants
to do complicated things.

Chicken<->   egg, we won't know which driver to use before we've probed
the mmc bus, and we cannot probe the bus before enabling the clks, etc.

The approach I took with brcmfmac is that upon module init I search the DT for "brcm,bcm43xx-fmac" compatible and get the clock and/or gpio resource and enable them before registering the sdio driver. The difficulty is probably when using the driver built-in as the clocks and gpios may not be available yet and we can not rely on deferred probing in module init stage.

I know, and that approach does not work, by the time the brcmfmac loads,
the mmc core has long probed the mmc bus and decided no one is home.

Ok. That is due to the non-removable property, right? I assumed a mmc rescan, which is (supposedly) triggered upon sdio driver registration, would subsequently find the device.

That is what I thought, but I tried without the non-removable property and
the sdio wifi was still not recognized.

Regards,

Hans