On 2018-01-30 23:47, Keith Busch wrote:
On Mon, Jan 29, 2018 at 10:34:44PM -0800, poza@xxxxxxxxxxxxxx wrote:
On 2018-01-30 11:59, Oza Pawandeep wrote:
> + Oza
>
> On Tue, Jan 30, 2018 at 7:41 AM, Sinan Kaya <okaya@xxxxxxxxxxxxxx>
> wrote:
>> On 1/29/2018 4:31 PM, Keith Busch wrote:
>>> + if (!work_busy(&dpc->work))
>>> + schedule_work(&dpc->work);
>>
>> Isn't there a race condition between the time that dpc_work() clears
>> PCI_EXP_DPC_STATUS
>> register and when work actually completes by returning from
>> dpc_work()?
>>
>> If the interrupt arrives just in this window, this code will not
>> schedule the work.
>>
>> --
>> Sinan Kaya
>> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
>> Technologies, Inc.
>> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
>> Linux Foundation Collaborative Project.
besides, there is one more problem which I was debugging:
if RP doesnt support MSI, then legacy interrupts are not well handled
and we get interrupt storm.
this is because;
PCI_EXP_DPC_STATUS_INTERRUPT is being cleared in deferred work.
which should get cleared in dpc_irq interrupt handler.
Okay, thanks for that information. I haven't got a DPC capable device
that
supports INTx, so that's a gap in my current testing capabilities.
It looks like as you're suggesting, we should clear DPC Interrupt
Status
in the top-half IRQ handler, and we should not see another DPC
interrupt
raised until after we clear DPC Trigger Status in the bottom-half.
yes that's right. I am preparing a patch with that, and testing it on
our platform.
please let me know on what branch should I post it ?
because other mail from Bjorn suggests me to post on pci/master. since
he will take care of merging it.
Regards,
Oza.
