[PATCH v4] ARM: omap: edma: add suspend suspend/resume hooks

Vaibhav Bedia vaibhav.bedia at gmail.com
Thu Nov 7 15:34:58 EST 2013


Hi Joel,

On Wed, Nov 6, 2013 at 12:36 PM, Joel Fernandes <joelf at ti.com> 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 at gmail.com> 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



More information about the linux-arm-kernel mailing list