Re: RFC: representing sdio devices oob interrupt, clks, etc. in device tree

[Tomasz Figa <tomasz.figa@gmail.com>]

I'm following this discussion continuously, but (un)fortunately I'm on
vacation right now and don't have much time to work on this, so sorry
for a very selective reply.

On 28.05.2014 11:42, Hans de Goede wrote:
> Hi,
> 
> On 05/27/2014 03:50 PM, Ulf Hansson wrote:
>> [snip]
>>
>> Powerup driver's ->probe():
>> Typically the "powerup driver" will need to register a few callback
>> functions towards the mmc core. Typically at mmc_of_parse(), those
>> callbacks will have to be connected to a particular mmc host.
>>
>> I would like to see three different callbacks, mirroring each of the
>> mmc_ios power_mode states MMC_POWER_OFF|UP|ON.
> 
> Hmm, can't we do something with runtime pm here instead? I would be
> nice if we could use the platform bus for this instead of inventing
> a new bus for this. Both from not needing to add extra count pov, but
> also from the pov of having a solution which other subsystems can
> later easily copy. I can even envision the parts of mmc_of_parse
> dealing with this being a separate function taking a child node as
> argument from day one, which can then hopefully later be moved out
> of the mmc subsys and be used elsewhere too (*).

This is actually a real use case, because we already have HSIC (USB with
heavily stripped down physical layer) modems on certain Samsung boards
and similarly to the kind of SDIO devices being discussed here they
can't be discovered until a certain power up sequence is done.
Analogically, the modem chip uses OOB interrupts and certain GPIO lines
for various purposes and they need to be provided by DT.

Moreover, there are already WLAN chips available that can use HSIC as
their host interface and I'm not talking here about some exotic
products, but rather widely recognized products of Broadcom (BCM4335),
Marvell (88W8797) or Qualcomm Atheros (AR6004).

My conclusion is that I see the discussion here being too much focused
on MMC, especially considering the fact that the whole problem doesn't
have anything to do with MMC, which is just used as (one of possible)
host interface.

IMHO, all we need here is a way to tell the MMC (or HSIC) core when to
look for a new device and when not (e.g. power down the host controller
completely). Anything else, including proper power sequencing is up to
the platform driver of such non-discoverable device - it's only its host
interface that is discoverable when enabled. I believe this simplistic
approach would lead to much less new code added, better reusability of
code (power sequencing independent of host interface) and no need to
create overly generic code, which usually turns out to be not generic
enough.

Best regards,
Tomasz