+ Russell
On 05/25/14 21:20, Hans de Goede wrote:
Hi,
On 05/25/2014 02:34 PM, Mark Brown wrote:
On Sat, May 24, 2014 at 12:06:30PM +0200, Hans de Goede wrote:
On 05/23/2014 06:27 PM, Mark Brown wrote:
On Fri, May 23, 2014 at 01:50:40PM +0200, Hans de Goede wrote:
On 05/23/2014 01:22 PM, Mark Brown wrote:
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.
We could just say that the mere presence of a child node with the right
properties is sufficient to trigger the bus to do the startup?
Yes, except that most involved property names are standardized, ie clocks,
and we want to be able to opt out of the KISS mmc core code for
(future) complex power on sequences.
This is why I'm suggesting keying off the specific compatible strings
for drivers that want to opt out of the helpers rather than having a
compatible string to enable the helpers (which may depend on the
particular Linux version if the feature sets of drivers change for
example).
If the device is sufficiently complicated to need a special power up
sequence I'd expect we'd be able to have a compatible string which would
provide enough information for us to figure things out.
Hmm, so what you're suggesting is indeed more of an opt out then my initial
opt-in to KISS powerup idea. So to be clear what you're suggesting is:
mmc core walks host mmc-child nodes. Loads drivers based on compatibles
there. The checks a flag field in the driver to see if the driver wants to
opt-out of the KISS powerup code. The problem with this is that it won't
Yes.
work reliable with modules, think the mmc probe being done from the ramdisk,
and the driver in question only being available from the rootfs. I really
Why is that a problem - if we have no driver for the device there is no
point in powering it up in the first place is there?
Well the driver may show up later, so if we only do the power-up once we have
a driver, this means we need to re-check if we need to do the powerup later.
Also the mmc people are very much against specifying a driver, as that is
something which should be probed not specified. I agree with them I've
already seen boards were more or less standardized sdio modules from different
vendors are used, they have various standard sdio powerup related things, like
an enable signal in standard places, but different editions of the boards
have different sdio modules soldered on, using different drivers.
I expect that with some care we can make all variants of these boards work with
a single dts file, by using a simple sdio wifi powerup mechanism, and after
that letting the mmc core figure out which module is actually soldered on.
believe that using opt-in with a compatible such as simple-sdio-powerup
is by far the safest thing to do, and as an added advantage we don't need
to worry about how to deal with the future complex power on cases at all,
we leave all the room in the world for various future scenarios. since as
soon as the simple-sdio-powerup compatible is not there the mmc core will
behave as it does today.
Please remember that the DT is *supposed* to be an ABI - systems are
supposed to be able to ship with a fixed DT and have it work with random
operating systems they have no knowledge of (and may not even exist at
the time the DT is being created). This means we can't rely on removing
a compatible string later on.
I know that the DT is an ABI, and I'm not arguing for removing support for
the simple-sdio-powerup compatible from the kernel when a more complex
case arrives, nor am I arguing to remove it from the DT for existing working
boards. The idea behind the simple-sdio-powerup compatible is that it makes
the simple powerup behavior opt-in. So if a new board comes along which
requires something more complex, the people working on this can do what ever
they want / need without the simple powerup code getting in the way, as
long as they don't *add* the simple-sdio-powerup compatible to their *new*
DT file.
Basically the idea behind the simple-sdio-powerup compatible is to make
the worst case scenario for more complex boards to be the scenario which
we have today, i.e. no support for sdio powerup at all, rather then having
something in place which actually may get in the way, making things worse
then they are today.
Hi Hans,
I recalled a recent patchset from Russell King. He was working on i.MX6
platform with brcmfmac device and ended reworking sdhci/mmc host
controller code in a series of patches [1]. Patch 34 might be similar to
what you are trying to accomplish.
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
