[lkml]   [2008]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SDIO: IO-Ready Bit
On Tue, 18 Mar 2008 13:00:34 +0200
"Tomas Winkler" <> wrote:

> I'm working on SDIO multi function device. One of the subdevices a
> system device (SYS) who's purpose among the others is to initialize
> the whole combo, mainly it's loads the firmware of the devices and
> kick the sub devices. Each of the sub devices has it's own driver.
> This dictates the order of the driver initialization and SYS device
> has to compete it's work before other subdeivces drivers can access
> the hardware. From hardware perspective device is ready when IO-Ready
> bit in SDIO is set.

What a delightfully unfriendly design...

> The first problem is that currently there is hard code timeout in
> sdio_enable_func instead of using TPLFE_ENABLE_TIMEOUT_VAL
> /*
> * FIXME: This should timeout based on information in the CIS,
> * but we don't have card to parse that yet.
> */
> timeout = jiffies + HZ
> This can be probably easily fixed. The significant issue is that this
> is done in busy wait loop and that probe functions are called in
> serially.

The SDIO spec doesn't really allow such a card to exist. So it's not surprising that things break. Does any stack support this odd-ball card?

> Since we cannot ensure that enumeration of SYS devices will be first
> the other sub devices will fail in their probe functions while calling
> sido_enable_func
> One option is to move the sdio_enable_func to be called from a work
> queue kicked from probe. This still requires non-busy wait timeout on
> IO-Ready bit and we cannot fail probe func
> if something goes wrong.
> Second option would be somehow split the sdio probe function across
> the enabled timeout.

I think it's a bit more complex than that. There are likely locks all over the place, both in the relevant driver and the driver model core, that makes this very difficult. Not to mention the fact that the correct timeout will be finite, and you never know how long it will take you to load the firmware.

A better approach is to simply have the drivers for your subfunctions synchronize things. Make sure noone calls sdio_enable_func() until the firmware has been loaded. This could even be done from user space in case you want to use a standard driver.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2008-03-18 12:37    [W:0.242 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site