Thread (49 messages) 49 messages, 7 authors, 2014-06-09

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

From: Olof Johansson <hidden>
Date: 2014-05-23 16:47:01
Also in: linux-arm-kernel, linux-mmc

On Thu, May 22, 2014 at 07:20:55PM +0200, Tomasz Figa wrote:
Hi,


On 22.05.2014 13:38, Hans de Goede wrote:
quoted
On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
quoted
On Thu, May 22, 2014 at 5:49 PM, Hans de Goede [off-list ref] wrote:
snip
quoted
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help