On 28 May 2014 13:03, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Wed, May 28, 2014 at 10:19:11AM +0200, Ulf Hansson wrote: >> On 27 May 2014 19:53, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> > This then either conflicts with cases where we need to describe the >> > actual contents of the slot with a compatible string or means that the >> > SDIO driver needs to handle powerup sequencing since we should be >> > binding to the first compatible we find. If the host controller driver >> > and/or subsystem is going to deal with the powering up it's not clear >> > that it specifically needs to be the compatible property that's used >> > to determine the powerup method, it could just be a boolean or a >> > 'power-method = blah' property (where blah is one of a series of strings >> > defining methods). Alternatively we could have separate nodes for the >> > slot and SDIO device but that feels meh. What's the hard requirement >> > for it to specifically be a compatible property? > >> Since the sdio bus is a discoverable bus, we must leave the "SDIO card >> device id" outside the information of the DT child node. Instead the >> "SDIO card device id" will be fetched once the card has been properly >> powered and initialized. From sdio bus' ->match(), the "SDIO func >> driver id" will be matched with the "SDIO card device id". > >> What we need to describe in the child node is only what "powerup >> driver" to use (an obviously it's resources). I don't see why there >> should be a conflict in using a compatible property, but I might be >> missing your point. > > I wouldn't assume that the SDIO bus will always be accurately > discoverable - hardware engineers can always repurpose things for other > purposes. Right! Though I think we should be able to handle most if these issues through the mmc quirks. > >> > There's also the need for the SDIO device to be able to get at the >> > resources provided and actively work with them at runtime if it wants to >> > manage things more actively (partial poweroff for low power states or >> > managing clock rates for example). > >> Yes, that's is also a reason to why I thought it would make sense to >> have a "powerup driver". Typically this driver should support runtime >> PM to handle these kind of fine grained power management. > > No, runtime PM isn't really fine grained - I'm talking about things > like starting and stopping individual resources or configuring them. Are you saying that you have several levels of quiescent mode of your external chip? > >> The SDIO func driver will have access (through the struct >> mmc_card|host) to the "powerup driver's" struct device, and can use >> pm_runtime_get|put() for it, to tell the "powerup driver" when it may >> go into power save state. > >> This kind of fine grained power management is not related directly to >> the SDIO specification, and should not be a part of the mmc core in my >> opinion. > >> If we don't have a compatible string in the DT child node of the mmc >> host, but just a DT property - is there a way to achieve the above >> anyway? > > I don't see any relationship between having compatible strings and the > ability to achieve things like that to be honest. Having compatible > strings has no real impact on what we can implement, the power driver > you're talking about can easily be library code or a feature of part of > the code that already exists - so long as we know what hardware is there > it's up to us how we interpret that. Agree. I am a bit puzzled of how such library should look like, but I suppose we need to be able to go to different power states through it. Typically the library may be invoked both from the mmc core to do power up/off and from the sdio func driver to handle power save. Does it make sense to you as well? Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
