On Wed, 27 Oct 2010, Alan Cox wrote: > > > > 2. Ideally host-driver driver should not tell the core to shut down > > > > the upper layers, instead the core should decide when to > > > > "disabled clock or cut the power". > > > > > > How will the core know ? > > > > > > > Are you saying that MMC core needs to be adapted first to RUNTIME PM? > > I think the runtime pm layer actually does help solve the problem - > because it allows both the driver and the core to defer power off. > > To me the fundamental problem is that the MMC/SDHCI core thinks it is > all knowing, when in reality silicon designers are far too good at > producing weird, whacky, broken and otherwise bizarre implementations. There are 2 levels of knowledge here: 1) The host controller doesn't know and must not try to know what the upper layer is doing with the card. This means that the host controller layer must not decide on its own to turn off the clock and/or cut power _to_ the card. Emphasis again: the host controller must not policy what happens to the card. Card issues and quirks are common to all controllers and best dealt with in the core. Duplicating that knowledge in all controller drivers is silly. 2) Host controller driver may optimize power usage further according to its own characteristics with actions that are transparent to both the core code and the card. For example, it is a damn good idea to shut down power to the _controller_ if power is also cut to the _card_. Or, the clock to the controller block may be gated while still keeping the clock to the card active when no activity has happened after a certain delay and that is compatible with the fact that card clock is still active, etc. I think tat the OMAP controller hardware is highly flexible and configurable in that regard. > Eventually it will all break because a design comes along which is > common, and sufficiently different. There are still things that are clearly belonging to different abstraction layers. And at the moment the OMAP controller driver is abusing those layers. > (PS: this should be discussed on the list not via some random collection > of email addresses) Indeed. Nicolas -- 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
