Hi Ohad,
On 07/08/2010 11:10 PM, ext Ohad Ben-Cohen wrote:
Hi Nicolas and Roger,
On Tue, Jul 6, 2010 at 8:42 PM, Nicolas Pitre<nico@xxxxxxxxxxx> wrote:
On Tue, 6 Jul 2010, Roger Quadros wrote:
If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then
the SDIO/MMC core should tackle it, just like it deals with supply for slots
with removable cards.
...
Another function pair would be needed instead, which would do almost
like the suspend/resume code is already doing. Something like:
Thanks a lot for your review and comments, and for taking the time to
present your approach.
you're welcome :)
I like it !
It'd allow us to lose the software (or fake if you want ;) card detect
mechanism, which is something that should have been added to each
platform we wanted to support.
We would only need to make it possible to deliver board-specific data
to the function driver (e.g., in the case of the wl1271, we need irq
and board_ref_clock data). That would require some board-level
platform-data configuration, which will be specific to the controller
to which the device is hardwired to. This data should propagate
through the host controller to the SDIO core so it would eventually be
why should platform data go through the host controller? You are already
creating a new platform device for wl1271_sdio just to pass platform_data so the
platform data for that can be passed directly from board files to this platform
device. It doesn't need to go via host controller.
I think this case is specific to wl1271. Ideally wl1271 should have used the
SDIO's in-band interrupt delivery mechanism and SDIO Configuration space to
provide this information to make it truly plug n play.
br,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
