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

[Olof Johansson <olof@lixom.net>]

On Thu, May 22, 2014 at 07:20:55PM +0200, Tomasz Figa wrote:
> Hi,
> 
> 
> On 22.05.2014 13:38, Hans de Goede wrote:
> > On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
> >> On Thu, May 22, 2014 at 5:49 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> 
> snip
> 
> >>> I've been thinking a bit about this, and it is a non trivial problem since
> >>> sdio devices are normally instantiated when probed, unlike ie spi devices
> >>> which are instantiated from devicetree.
> >>>
> >>> Adding device tree instantiation of sdio devices seems like a bad idea, as
> >>> then we get 2 vastly different device instantiation paths. Still we need some
> >>> way to get power and clks setup before the mmc host initializes.
> 
> What about introducing some extra callbacks to mmc drivers to build
> driver data and control power?

The MMC bus is probable, and there should be no need to put any information in
the device tree to pair up the right driver with the right device. The only
thing we should need is hardware description w.r.t. reset/power/clock lines.

It's pretty common during development to have a couple of different vendor
modules. Reset sequences and requirements might not be identical between them,
but in reality they all work well enough using the common settings.


Besides, where it ends up in the kernel implementation is mostly irrelevant, in
some ways. We can refactor and move things as needed at any time. The only
thing that needs to be reasonably stable (and/or only be expanded on, not
redefined) is the DT binding. So I'd rather see something KISS go in now,
implementation-wise (with a sane and simple binding), then getting stuck in
this infinite polishing of just how the kernel-side implementation should be.

This is one of the major missing pieces to make a lot of ARM systems usable
with a mainline kernel, since everybody use some out-of-tree solution today
(not necessarily hacks, but still not shared code). I'd really like to see it
resolved soon.

I'm OK in principle with Hans' proposed solution, as long as it provides the
properties I need on exynos5250-snow (and the new peach_pit/pi platforms).


-Olof