On Tue, May 15, 2012 at 01:14:29PM -0700, Tony Lindgren wrote: > * Felipe Balbi <balbi@xxxxxx> [120514 12:41]: > > On Mon, May 14, 2012 at 11:37:43AM -0700, Tony Lindgren wrote: > > > * Tony Lindgren <tony@xxxxxxxxxxx> [120514 11:19]: > > > > * Felipe Balbi <balbi@xxxxxx> [120514 11:04]: > > > > > > > > > > That whole MMC card detection is also pretty screwed up. Balaji/Venkat, > > > > > can you guys look into that ? Probably making something generic using a > > > > > threaded IRQ handler ? > > > > > > > > > > I mean, all the MMC core should need is an IRQ number (through GPIOs or > > > > > not doesn't/shouldn't matter) and it should be able to use a threaded > > > > > IRQ handler to kick the card detection/initialization. > > > > > > > > That's mostly done.. Just need to update the patches for it. > > > > > > Mostly done meaning "all the MMC core should need is an IRQ number" > > > part that is :) > > > > but you've done it for omap_hsmmc.c, right ? What I meant is that the > > whole card detection should be done at the MMC framework level. > > Yes what I did was just try to start gettting rid of the platform > callbacks. > > > I mean, if we tell MMC core what's the card detect IRQ number, it should > > be able to implement a generic version of omap_hsmmc_detect(). All that > > thing does is read the current gpio status number and call > > mmc_detect_change(). > > > > mmc_detect_change() then kicks a delayed work, which shouldn't be needed > > because omap_hsmmc_detect() (or the generic of it) is already using a > > threaded IRQ. > > Yeah maybe it's doable.. The MMC driver needs to read the status of the > card insert, but maybe that should be just just gpio_get_value(). > > Then ideally the MMC driver would not have any knowledge how the GPIO > is handled as it can come from whatever gpiochip using internal GPIO > or TWL GPIO. correct. -- balbi
Attachment:
signature.asc
Description: Digital signature
