* Sekhar Nori [151203 07:25]:
> On Thursday 03 December 2015 08:32 PM, Tony Lindgren wrote:
> >
> > Yes we should naturally fix up the kernel locking.
>
> Alright. Thanks!
>
> >
> > Please also add something like "enable debug for more information"
> > to the warning. And then print out the cu
On Thursday 03 December 2015 08:32 PM, Tony Lindgren wrote:
> * Sekhar Nori [151203 03:29]:
>> On Tuesday 20 October 2015 08:22 PM, Tony Lindgren wrote:
>>>
>>> OK thanks for testing. My guess from the above list would be EDMA
>>> or CPSW missing a flush of posted write. Maybe try adding a readbac
* Sekhar Nori [151203 03:29]:
> On Tuesday 20 October 2015 08:22 PM, Tony Lindgren wrote:
> >
> > OK thanks for testing. My guess from the above list would be EDMA
> > or CPSW missing a flush of posted write. Maybe try adding a readback
> > of the related device revision register after acking the
Hi Tony,
On Tuesday 20 October 2015 08:22 PM, Tony Lindgren wrote:
> * John Ogness [151020 00:33]:
>> On 2015-10-20, Sekhar Nori wrote:
Do you know what really is causing the spurious interrupts in your
case?
>>>
>>> No, not yet.
>>
>> According to the TRM this is normal behavior if co
* John Ogness [151020 00:33]:
> On 2015-10-20, Sekhar Nori wrote:
> >> Do you know what really is causing the spurious interrupts in your
> >> case?
> >
> > No, not yet.
>
> According to the TRM this is normal behavior if conditions that might
> affect priority are changed during priority sortin
On 2015-10-20, Sekhar Nori wrote:
>> Do you know what really is causing the spurious interrupts in your
>> case?
>
> No, not yet.
According to the TRM this is normal behavior if conditions that might
affect priority are changed during priority sorting.
6.2.5 ARM A8 INTC Spurious Interrupt Ha
On Monday 19 October 2015 08:20 PM, Tony Lindgren wrote:
> Hi,
>
> * Sekhar Nori [151019 02:51]:
>> Under some conditions, irq sorting procedure used by INTC can go wrong
>> resulting in a spurious irq getting reported.
>>
>> This condition is flagged by INTC by setting "Spurious IRQ Flag" in SIR
Hi,
* Sekhar Nori [151019 02:51]:
> Under some conditions, irq sorting procedure used by INTC can go wrong
> resulting in a spurious irq getting reported.
>
> This condition is flagged by INTC by setting "Spurious IRQ Flag" in SIR
> register to 0x1ff. Section 6.2.5 of AM335x TRM revised Jun
On Mon, 19 Oct 2015, Sekhar Nori wrote:
> + /*
> + * A spurious IRQ can result if interrupt that triggered the
> + * sorting is no longer active during the sorting (10 INTC
> + * functional clock cycles after interrupt assertion). Or a
> + * change in interrupt mask affected