On 27 May 2014 20:55, Olof Johansson <olof@xxxxxxxxx> wrote: > On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote: >> On Tue, May 27, 2014 at 03:50:33PM +0200, Ulf Hansson wrote: >> >> > To describe the HW in DT, the embedded SDIO card (actually it could be >> > any type of embedded card) shall be modelled as a child node to the >> > mmc host in DT. Similar to what you have proposed, but with the >> > difference that the child node _must_ contain a DT compatible string, >> > which means a "powerup-driver" can be probed. >> >> > Yes, I understand we might need one DT compatible string per board, >> > but that's because we need to model the hardware - and it differs. >> >> > To clarify my view, we do need a "powerup-driver" and the primary >> > reason is that we must not model "power up sequences" within DT. >> > Typically I see the "powerup-driver" as a simple platform driver >> > attached to the platform bus, but I that could of course differ. >> >> 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? > > +1. Just because we have a subnode in a device tree, we don't have to have > a driver bind against it. The MMC core code could go down into the subnodes, > find a "power-method = <foo>" property and go ahead and parse the rest of it. > There's no requirement that we do this through the Linux driver model of > probe(), etc. Using "power-method" might work. It's would simplify things quite a bit regarding the synchronization point, in the mmc_of_parse(). But... does it prevent us from handling fine grained power management through runtime PM? See more comments below. > >> > The slot will be the first level of child node under the mmc host, >> > then each slot may have a child node which models the embedded card. >> > But, let's leave that discussion for now. :-) >> >> OK, that's the separate node for the slot and device. >> >> > Powerup driver's ->probe(): >> > Typically the "powerup driver" will need to register a few callback >> > functions towards the mmc core. Typically at mmc_of_parse(), those >> > callbacks will have to be connected to a particular mmc host. >> >> > I would like to see three different callbacks, mirroring each of the >> > mmc_ios power_mode states MMC_POWER_OFF|UP|ON. >> >> > The power up sequence, performed by the mmc core: >> > The mmc_power_up|off functions, will invoke the registered "powerup >> > driver's" callbacks if they exists for the particular host it operates >> > on. >> >> 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). > > Again, I think it gets overly complicated by using a full driver for the > power management. Abstracted out into something separate and scalable > as number of devices grow? Sure, definitely. As a driver? Not convinced. To handle the fine grained power management, runtime PM is for sure what we should use here. So, then we need a struct device to be created to represent the power-method. Now, if we don't implement this through a "powerup driver" which may have runtime PM callbacks set up - how do we handle this? I suppose we could register a specific "mmc power bus", and create/add the struct device representing the power-method to it. Would that work? Kind regards Ulf Hansson -- 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
