Hi Joel,
On Wed, Nov 6, 2013 at 12:36 PM, Joel Fernandes <joelf@xxxxxx> wrote:
> Hi Vaibhav,
>
> On 10/31/2013 05:25 PM, Vaibhav Bedia wrote:
>> Hi Daniel,
>>
>> On Wed, Oct 30, 2013 at 4:21 PM, Daniel Mack <zonque@xxxxxxxxx> wrote:
>> [...]
>>> +
>>> +static SIMPLE_DEV_PM_OPS(edma_pm_ops, edma_pm_suspend, edma_pm_resume);
>>> +
>>> static struct platform_driver edma_driver = {
>>> .driver = {
>>> .name = "edma",
>>> + .pm = &edma_pm_ops,
>>> .of_match_table = edma_of_ids,
>>> },
>>
>> A while back we discovered a nasty race condition here that had us move the EDMA
>> PM callbacks to the noirq phase. IIRC the MMC driver was resuming
>> before the EDMA
>> driver had a chance to run and that was leading to a deadlock. I am
>> not sure how to force
>> this scenario but i do remember spending time debugging this on a
>> random codebase.
>> Maybe some else has some better ideas on how to force this race condition...
>
> I think you're talking about the patch at [1] which is not upstream. A quick
Yeah that's the one.
> question with my limited knowledge of suspend/resume- How can there be pending
> I/O operations between suspend/resume cycles? The sync is done before suspend,
> so I don't understand how one is receiving a response from the card after resume
> before EDMA can resume? I'd imagine that until all devices are resumed, there
> will be no I/O operation issued. Let me know your thoughts.
>
Sadly the commit message does not capture the details to the level it
should have.
>From what i remember, during the resume operation the driver was waiting for the
response of the first cmd that it sends and that never happened since the driver
was setup to use DMA mode and the EDMA driver hadn't resumed. Ideally such
issues should have been noticed a long time back. One more thing to note is that
the MMC controller on AMx series does not have the internal DMA like OMAPx.
However i am not sure how much that, if at all, plays a role here.
Maybe someone internally still has a copy of the analysis done and you could
try to hunt that down for more details. In case you do it would be
good to have it
mentioned here.
Regards,
Vaibhav
--
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
