[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
used for rx and tx respectively.

Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
 drivers/net/ethernet/ti/davinci_cpdma.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index f862918..afe14a6 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -487,6 +487,8 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
 void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
 {
 	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
+	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 1);
+	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 2);
 }
 
 struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
-- 
1.7.9.5

[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
used for rx and tx respectively.

Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
 drivers/net/ethernet/ti/davinci_cpdma.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index f862918..afe14a6 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -487,6 +487,8 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
 void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
 {
 	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
+	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 1);
+	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 2);
 }
 
 struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
-- 
1.7.9.5

[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

CPDMA interrupts are not properly acknowledged which leads to interrupt
storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
used for rx and tx respectively.

Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
 drivers/net/ethernet/ti/davinci_cpdma.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index f862918..afe14a6 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -487,6 +487,8 @@ int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable)
 void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr)
 {
 	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 0);
+	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 1);
+	dma_reg_write(ctlr, CPDMA_MACEOIVECTOR, 2);
 }
 
 struct cpdma_chan *cpdma_chan_create(struct cpdma_ctlr *ctlr, int chan_num,
-- 
1.7.9.5

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Koen Kooi]

Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:

> CPDMA interrupts are not properly acknowledged which leads to interrupt
> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
> used for rx and tx respectively.

A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Koen Kooi]

Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:

> CPDMA interrupts are not properly acknowledged which leads to interrupt
> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
> used for rx and tx respectively.

A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?

[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Koen Kooi]

Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:

> CPDMA interrupts are not properly acknowledged which leads to interrupt
> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
> used for rx and tx respectively.

A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

On 1/31/2013 1:33 AM, Koen Kooi wrote:
> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>
>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>> used for rx and tx respectively.
> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
Existing driver implementation is also complies with TRM. What Pantelis 
added
additionally are non-napi implementation, handled cpdma processed tx and rx
processing separately and renamed wr_reg as per TRM naming convention.. 
Also he
has added a dummy reading tx/rx stat which is mentioned in TRM, but this 
stat
is required only when using multichannel for data transfer. Current 
implementation
of CPSW driver uses only channel 0 of Tx and Rx channels respectively 
for transmission
and reading stat doesn't gets any effect in interrupt acknowledgment.

Since both tx and rx are processed in same napi api, so i have added 
interrupt
acknowledgment to the same existing api.

Regards
Mugunthan V N

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

On 1/31/2013 1:33 AM, Koen Kooi wrote:
> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>
>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>> used for rx and tx respectively.
> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
Existing driver implementation is also complies with TRM. What Pantelis 
added
additionally are non-napi implementation, handled cpdma processed tx and rx
processing separately and renamed wr_reg as per TRM naming convention.. 
Also he
has added a dummy reading tx/rx stat which is mentioned in TRM, but this 
stat
is required only when using multichannel for data transfer. Current 
implementation
of CPSW driver uses only channel 0 of Tx and Rx channels respectively 
for transmission
and reading stat doesn't gets any effect in interrupt acknowledgment.

Since both tx and rx are processed in same napi api, so i have added 
interrupt
acknowledgment to the same existing api.

Regards
Mugunthan V N

[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

On 1/31/2013 1:33 AM, Koen Kooi wrote:
> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>
>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>> used for rx and tx respectively.
> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
Existing driver implementation is also complies with TRM. What Pantelis 
added
additionally are non-napi implementation, handled cpdma processed tx and rx
processing separately and renamed wr_reg as per TRM naming convention.. 
Also he
has added a dummy reading tx/rx stat which is mentioned in TRM, but this 
stat
is required only when using multichannel for data transfer. Current 
implementation
of CPSW driver uses only channel 0 of Tx and Rx channels respectively 
for transmission
and reading stat doesn't gets any effect in interrupt acknowledgment.

Since both tx and rx are processed in same napi api, so i have added 
interrupt
acknowledgment to the same existing api.

Regards
Mugunthan V N

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Pantelis Antoniou]

Hi
On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote:

> On 1/31/2013 1:33 AM, Koen Kooi wrote:
>> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>> 
>>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>>> used for rx and tx respectively.
>> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
> Existing driver implementation is also complies with TRM. What Pantelis added
> additionally are non-napi implementation, handled cpdma processed tx and rx
> processing separately and renamed wr_reg as per TRM naming convention.. Also he
> has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat
> is required only when using multichannel for data transfer. Current implementation
> of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission
> and reading stat doesn't gets any effect in interrupt acknowledgment.
> 
> Since both tx and rx are processed in same napi api, so i have added interrupt
> acknowledgment to the same existing api.
> 


First of all, this method of not needing to read the stat registers besides when
using multichannel for data transfers is never described anywhere in any manual, 
or in the driver sources.

Secondly, I find the method of ack-ing all interrupt sources problematic.
Consider the following sequence

Rx-interrupt ---> |                         |
                  | IRQ handler             |
                  | schedules NAPI          |
                  | disables interrupts --> | cpsw_poll()
                  |                         | handle Rx
Tx-interrupt ---> |-------------------------|-------------
                  |                         | ack Rx & Tx IRQ
                  |                         | enable interrupts

When will the Tx interrupt get handled? Is it guaranteed that the DMA
logic will assert the Tx interrupt when the interrupts are enabled, even
though the interrupt was previously acked? It is not clear in the TRM.

Another problem that I see is that the other interrupts (MISC) are not supposed
to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path 
as far as I know.


> Regards
> Mugunthan V N

Regards

-- Pantelis

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Pantelis Antoniou]

Hi
On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote:

> On 1/31/2013 1:33 AM, Koen Kooi wrote:
>> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>> 
>>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>>> used for rx and tx respectively.
>> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
> Existing driver implementation is also complies with TRM. What Pantelis added
> additionally are non-napi implementation, handled cpdma processed tx and rx
> processing separately and renamed wr_reg as per TRM naming convention.. Also he
> has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat
> is required only when using multichannel for data transfer. Current implementation
> of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission
> and reading stat doesn't gets any effect in interrupt acknowledgment.
> 
> Since both tx and rx are processed in same napi api, so i have added interrupt
> acknowledgment to the same existing api.
> 


First of all, this method of not needing to read the stat registers besides when
using multichannel for data transfers is never described anywhere in any manual, 
or in the driver sources.

Secondly, I find the method of ack-ing all interrupt sources problematic.
Consider the following sequence

Rx-interrupt ---> |                         |
                  | IRQ handler             |
                  | schedules NAPI          |
                  | disables interrupts --> | cpsw_poll()
                  |                         | handle Rx
Tx-interrupt ---> |-------------------------|-------------
                  |                         | ack Rx & Tx IRQ
                  |                         | enable interrupts

When will the Tx interrupt get handled? Is it guaranteed that the DMA
logic will assert the Tx interrupt when the interrupts are enabled, even
though the interrupt was previously acked? It is not clear in the TRM.

Another problem that I see is that the other interrupts (MISC) are not supposed
to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path 
as far as I know.


> Regards
> Mugunthan V N

Regards

-- Pantelis

[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Pantelis Antoniou]

Hi
On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote:

> On 1/31/2013 1:33 AM, Koen Kooi wrote:
>> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>> 
>>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>>> used for rx and tx respectively.
>> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
> Existing driver implementation is also complies with TRM. What Pantelis added
> additionally are non-napi implementation, handled cpdma processed tx and rx
> processing separately and renamed wr_reg as per TRM naming convention.. Also he
> has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat
> is required only when using multichannel for data transfer. Current implementation
> of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission
> and reading stat doesn't gets any effect in interrupt acknowledgment.
> 
> Since both tx and rx are processed in same napi api, so i have added interrupt
> acknowledgment to the same existing api.
> 


First of all, this method of not needing to read the stat registers besides when
using multichannel for data transfers is never described anywhere in any manual, 
or in the driver sources.

Secondly, I find the method of ack-ing all interrupt sources problematic.
Consider the following sequence

Rx-interrupt ---> |                         |
                  | IRQ handler             |
                  | schedules NAPI          |
                  | disables interrupts --> | cpsw_poll()
                  |                         | handle Rx
Tx-interrupt ---> |-------------------------|-------------
                  |                         | ack Rx & Tx IRQ
                  |                         | enable interrupts

When will the Tx interrupt get handled? Is it guaranteed that the DMA
logic will assert the Tx interrupt when the interrupts are enabled, even
though the interrupt was previously acked? It is not clear in the TRM.

Another problem that I see is that the other interrupts (MISC) are not supposed
to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path 
as far as I know.


> Regards
> Mugunthan V N

Regards

-- Pantelis

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

Pantelis

On 1/31/2013 4:52 PM, Pantelis Antoniou wrote:
> Hi
> On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote:
>
>> On 1/31/2013 1:33 AM, Koen Kooi wrote:
>>> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>>>
>>>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>>>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>>>> used for rx and tx respectively.
>>> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
>> Existing driver implementation is also complies with TRM. What Pantelis added
>> additionally are non-napi implementation, handled cpdma processed tx and rx
>> processing separately and renamed wr_reg as per TRM naming convention.. Also he
>> has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat
>> is required only when using multichannel for data transfer. Current implementation
>> of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission
>> and reading stat doesn't gets any effect in interrupt acknowledgment.
>>
>> Since both tx and rx are processed in same napi api, so i have added interrupt
>> acknowledgment to the same existing api.
>>
>
> First of all, this method of not needing to read the stat registers besides when
> using multichannel for data transfers is never described anywhere in any manual,
> or in the driver sources.
>
> Secondly, I find the method of ack-ing all interrupt sources problematic.
> Consider the following sequence
>
> Rx-interrupt ---> |                         |
>                    | IRQ handler             |
>                    | schedules NAPI          |
>                    | disables interrupts --> | cpsw_poll()
>                    |                         | handle Rx
> Tx-interrupt ---> |-------------------------|-------------
>                    |                         | ack Rx & Tx IRQ
>                    |                         | enable interrupts
>
> When will the Tx interrupt get handled? Is it guaranteed that the DMA
> logic will assert the Tx interrupt when the interrupts are enabled, even
> though the interrupt was previously acked? It is not clear in the TRM.
Need to check with the IP owner with this corner case. Simulating this 
will be difficult
because even if driver misses the interrupt in next rx/tx interrupt it 
will be serviced.
>
> Another problem that I see is that the other interrupts (MISC) are not supposed
> to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path
> as far as I know.
I agree that napi should not be used for MISC interrupts.

Regards
Mugunthan V N
>
>
>> Regards
>> Mugunthan V N
> Regards
>
> -- Pantelis
>

Re: [PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

Pantelis

On 1/31/2013 4:52 PM, Pantelis Antoniou wrote:
> Hi
> On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote:
>
>> On 1/31/2013 1:33 AM, Koen Kooi wrote:
>>> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>>>
>>>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>>>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>>>> used for rx and tx respectively.
>>> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
>> Existing driver implementation is also complies with TRM. What Pantelis added
>> additionally are non-napi implementation, handled cpdma processed tx and rx
>> processing separately and renamed wr_reg as per TRM naming convention.. Also he
>> has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat
>> is required only when using multichannel for data transfer. Current implementation
>> of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission
>> and reading stat doesn't gets any effect in interrupt acknowledgment.
>>
>> Since both tx and rx are processed in same napi api, so i have added interrupt
>> acknowledgment to the same existing api.
>>
>
> First of all, this method of not needing to read the stat registers besides when
> using multichannel for data transfers is never described anywhere in any manual,
> or in the driver sources.
>
> Secondly, I find the method of ack-ing all interrupt sources problematic.
> Consider the following sequence
>
> Rx-interrupt ---> |                         |
>                    | IRQ handler             |
>                    | schedules NAPI          |
>                    | disables interrupts --> | cpsw_poll()
>                    |                         | handle Rx
> Tx-interrupt ---> |-------------------------|-------------
>                    |                         | ack Rx & Tx IRQ
>                    |                         | enable interrupts
>
> When will the Tx interrupt get handled? Is it guaranteed that the DMA
> logic will assert the Tx interrupt when the interrupts are enabled, even
> though the interrupt was previously acked? It is not clear in the TRM.
Need to check with the IP owner with this corner case. Simulating this 
will be difficult
because even if driver misses the interrupt in next rx/tx interrupt it 
will be serviced.
>
> Another problem that I see is that the other interrupts (MISC) are not supposed
> to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path
> as far as I know.
I agree that napi should not be used for MISC interrupts.

Regards
Mugunthan V N
>
>
>> Regards
>> Mugunthan V N
> Regards
>
> -- Pantelis
>

[PATCH 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly

[Mugunthan V N]

Pantelis

On 1/31/2013 4:52 PM, Pantelis Antoniou wrote:
> Hi
> On Jan 31, 2013, at 12:17 PM, Mugunthan V N wrote:
>
>> On 1/31/2013 1:33 AM, Koen Kooi wrote:
>>> Op 30 jan. 2013, om 20:56 heeft Mugunthan V N <mugunthanvnm@ti.com> het volgende geschreven:
>>>
>>>> CPDMA interrupts are not properly acknowledged which leads to interrupt
>>>> storm, only cpdma interrupt 0 is acknowledged in Davinci CPDMA driver.
>>>> Changed cpdma_ctlr_eoi api to acknowledge 1 and 2 interrupts which are
>>>> used for rx and tx respectively.
>>> A brief inspection shows that this still isn't following the TRM, but Pantelis' patch does. Can you please fix this driver to follow the TRM and make it work on both PG1.0 and PG2.0 instead of papering over bugs instead of fixing them properly?
>> Existing driver implementation is also complies with TRM. What Pantelis added
>> additionally are non-napi implementation, handled cpdma processed tx and rx
>> processing separately and renamed wr_reg as per TRM naming convention.. Also he
>> has added a dummy reading tx/rx stat which is mentioned in TRM, but this stat
>> is required only when using multichannel for data transfer. Current implementation
>> of CPSW driver uses only channel 0 of Tx and Rx channels respectively for transmission
>> and reading stat doesn't gets any effect in interrupt acknowledgment.
>>
>> Since both tx and rx are processed in same napi api, so i have added interrupt
>> acknowledgment to the same existing api.
>>
>
> First of all, this method of not needing to read the stat registers besides when
> using multichannel for data transfers is never described anywhere in any manual,
> or in the driver sources.
>
> Secondly, I find the method of ack-ing all interrupt sources problematic.
> Consider the following sequence
>
> Rx-interrupt ---> |                         |
>                    | IRQ handler             |
>                    | schedules NAPI          |
>                    | disables interrupts --> | cpsw_poll()
>                    |                         | handle Rx
> Tx-interrupt ---> |-------------------------|-------------
>                    |                         | ack Rx & Tx IRQ
>                    |                         | enable interrupts
>
> When will the Tx interrupt get handled? Is it guaranteed that the DMA
> logic will assert the Tx interrupt when the interrupts are enabled, even
> though the interrupt was previously acked? It is not clear in the TRM.
Need to check with the IP owner with this corner case. Simulating this 
will be difficult
because even if driver misses the interrupt in next rx/tx interrupt it 
will be serviced.
>
> Another problem that I see is that the other interrupts (MISC) are not supposed
> to be routed to the napi cpsw_poll() function at all. NAPI is for the tx/rx path
> as far as I know.
I agree that napi should not be used for MISC interrupts.

Regards
Mugunthan V N
>
>
>> Regards
>> Mugunthan V N
> Regards
>
> -- Pantelis
>