>>  drivers/mmc/card/block.c |   96
>++++++++++++++++++++++++----------------------
>>  drivers/mmc/core/core.c  |   20 ++++++++++
>>  drivers/mmc/core/mmc.c   |   70 ++++++++++++++++++++++++++++++++-
>>  drivers/mmc/host/sdhci.c |   49 ++++++++++++++++++++++-
>
>This patch looks like it is *very* intrusive. There's a big chance that you 
>will
>be kicked from upstream :)

Yes. I know that it'll be easier for upstream acceptance if we don't change mmc 
core layer code any more. But seems it's impossible to limit the eMMC mutex 
usage only in host controller driver. 

If apply the eMMC mutex only in host controller driver, it'll have to acquire 
the eMMC mutex ownership before every mmc command start and release it after 
that command finish. That means, the SCU can interrupt the normal mmc driver 
operations when every command finishes. This will break the normal 
functionality of mmc drvier.

So we have to change the mmc core driver to protect the normal mmc driver 
operations in a coarse granularity.

>The semantic does not sound like there is a very difference from what 
>runtime_pm
>patches are doing.
>You will need an acquire_ownership() at the same place you would need a
>pm_runtime_get()
>
>Why an acquire_ownership() could not be called in the runtime_pm resume
>callback?
>And release_ownership() could be called in the runtime_pm suspend callback?

Yes, acquire_ownership should be called before runtime_pm_resume, and 
release_ownership should be called after runtime_pm_suspend. Actually, we have 
done it in our driver.

Since I submitted 'mmc runtime PM' and 'eMMC mutex' as two independent patch 
series, that is, they are both generated based on a 'clean' meego kernel 
respectively. So, the acquire_ownership/release_ownership APIs in 'eMMC mutex' 
patch can not be found in the 'mmc runtime PM' patch.

Once one patch (for example, the 'mmc runtime PM' patch) is accepted by MeeGo, 
I'll resubmitted the other patch (eMMC mutex patch).

Thanks.

Regards,
Yunpeng

_______________________________________________
MeeGo-kernel mailing list
[email protected]
http://lists.meego.com/listinfo/meego-kernel

Reply via email to