* James Cameron <qu...@laptop.org> [140701 10:05]: > On Tue, Jul 01, 2014 at 12:02:25AM -0700, Bing Zhao wrote: > > Hi James, > > > > > On Mon, Jun 30, 2014 at 11:44:29PM -0700, Bing Zhao wrote: > > > > I may have missed something, but doesn't the MMC_POWER_OFF and > > > > MMC_POWER_ON|UP handling in controller driver help? > > > > Anyway the clocks/GPIOs/regulators are sort of platform dependent. > > > > Would it be better putting it in /arch/arm/mach-xxxxx/? > > > > > > Wouldn't device tree for mmc be better? > > > > Yes, device tree is better for defining clocks/GPIO/regulators, etc. > > But I guess the reset logic (making use of these definitions) cannot > > be device tree? > > I think the reset logic can exist, but does nothing unless the device > tree definitions are present.
It might be possible to support the SDIO card specific clocks/GPIOs/regulators the MMC bus driver. But that may not work well in the long run as those pins are not connected to the MMC bus at all. If we wanted to explore adding card specific features to the MMC bus, I guess we should have: - Card reset-gpios - Card specific regulators on the card controlled by a GPIO - External card specific regulators - Card specific idle status pin (no idea what these pins do on some of the mwifiex cards though?) And then these would have to be configured to get the SDIO card to probe. And they should be controllable also from user space to reset a card or to power it off. Then if we get a device that muxes two different SDIO cards on the same bus, then what do we do? They may both have their own regulators and reset GPIO pins. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
