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. > > 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. -Olof -- 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
