[RFC] sh_eth: use RNC mode for R8A7790

[RFC] sh_eth: use RNC mode for R8A7790

[Ben Dooks]

The current behaviour of the sh_eth driver is not to use the RNC bit
for the receive ring. This means that every packet recieved is not only
generating an IRQ but it also stops the receive ring DMA as well until
the driver re-enables it after unloading the packet.

This means that a number of the following errors are generated due to
the receive packet FIFO overflowing due to nowhere to put packets:

	net eth0: Receive FIFO Overflow

Setting the RMCR_RNC configuration has so far been tested with an NFS
root filesystem and the driver has not failed yet. It is not yet known
why this is not set for R8A779x operation (Feedback on this issue or
other testing is welcome)

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
 drivers/net/ethernet/renesas/sh_eth.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index 942f1a9..7b02b70 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -467,6 +467,7 @@ static struct sh_eth_cpu_data r8a779x_data = {
 	.ecsr_value	= ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
 	.ecsipr_value	= ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
 	.eesipr_value	= 0x01ff009f,
+	.rmcr_value	= RMCR_RNC,
 
 	.tx_check	= EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
 	.eesr_err_check	= EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
-- 
1.9.0

Re: [RFC] sh_eth: use RNC mode for R8A7790

[Sergei Shtylyov]

Hello.

On 03/28/2014 07:46 PM, Ben Dooks wrote:

> The current behaviour of the sh_eth driver is not to use the RNC bit
> for the receive ring. This means that every packet recieved is not only
> generating an IRQ but it also stops the receive ring DMA as well until
> the driver re-enables it after unloading the packet.

> This means that a number of the following errors are generated due to
> the receive packet FIFO overflowing due to nowhere to put packets:

> 	net eth0: Receive FIFO Overflow

> Setting the RMCR_RNC configuration has so far been tested with an NFS
> root filesystem and the driver has not failed yet. It is not yet known
> why this is not set for R8A779x operation

    The reason is simple: it's not set on almost all 100 Mbs devices except 
SH7757 (and most recently added R7S72100), so this was a matter of copy-paste. 
I've had setting this bit on at least R-Car devices on my aganda for some time 
but couldn't get to it yet.

> (Feedback on this issue or other testing is welcome)

    OK, I'll try it with netperf UDP test known to generate handful of the 
aforementioned errors, when I have time.

WBR, Sergei

Re: [RFC] sh_eth: use RNC mode for R8A7790

[Ben Dooks]

On 28/03/14 20:38, Sergei Shtylyov wrote:
> Hello.
>
> On 03/28/2014 07:46 PM, Ben Dooks wrote:
>
>> The current behaviour of the sh_eth driver is not to use the RNC bit
>> for the receive ring. This means that every packet recieved is not only
>> generating an IRQ but it also stops the receive ring DMA as well until
>> the driver re-enables it after unloading the packet.
>
>> This means that a number of the following errors are generated due to
>> the receive packet FIFO overflowing due to nowhere to put packets:
>
>>     net eth0: Receive FIFO Overflow
>
>> Setting the RMCR_RNC configuration has so far been tested with an NFS
>> root filesystem and the driver has not failed yet. It is not yet known
>> why this is not set for R8A779x operation
>
>     The reason is simple: it's not set on almost all 100 Mbs devices
> except SH7757 (and most recently added R7S72100), so this was a matter
> of copy-paste. I've had setting this bit on at least R-Car devices on my
> aganda for some time but couldn't get to it yet.
>
>> (Feedback on this issue or other testing is welcome)
>
>     OK, I'll try it with netperf UDP test known to generate handful of
> the aforementioned errors, when I have time.

I find the best way is to either use NFS-root or turn on all the
locking debugging, it seems to slow things down enough for the
RX FIFO to overflow.

 From a quick debug, I saw that each RX IRQ delivered one packet
from the ring buffer before requiring the hardware received to
be re-started.

So far I have not had any chance to make any speed tests, however
it has cleared off a lot of the fifo messages off my nfs-root tests
here. I've had a ring-error, but that was due to another driver
holding interrupts for far too long.

-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: [RFC] sh_eth: use RNC mode for R8A7790

[Ben Dooks]

On 28/03/14 20:38, Sergei Shtylyov wrote:
> Hello.
>
> On 03/28/2014 07:46 PM, Ben Dooks wrote:
>
>> The current behaviour of the sh_eth driver is not to use the RNC bit
>> for the receive ring. This means that every packet recieved is not only
>> generating an IRQ but it also stops the receive ring DMA as well until
>> the driver re-enables it after unloading the packet.
>
>> This means that a number of the following errors are generated due to
>> the receive packet FIFO overflowing due to nowhere to put packets:
>
>>     net eth0: Receive FIFO Overflow
>
>> Setting the RMCR_RNC configuration has so far been tested with an NFS
>> root filesystem and the driver has not failed yet. It is not yet known
>> why this is not set for R8A779x operation
>
>     The reason is simple: it's not set on almost all 100 Mbs devices
> except SH7757 (and most recently added R7S72100), so this was a matter
> of copy-paste. I've had setting this bit on at least R-Car devices on my
> aganda for some time but couldn't get to it yet.
>
>> (Feedback on this issue or other testing is welcome)
>
>     OK, I'll try it with netperf UDP test known to generate handful of
> the aforementioned errors, when I have time.
>
> WBR, Sergei

Has anyone had time to look at this?


-- 
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius

Re: [RFC] sh_eth: use RNC mode for R8A7790

[Geert Uytterhoeven]

Hi Ben,

On Mon, Apr 14, 2014 at 2:47 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
> On 28/03/14 20:38, Sergei Shtylyov wrote:
>> On 03/28/2014 07:46 PM, Ben Dooks wrote:
>>> The current behaviour of the sh_eth driver is not to use the RNC bit
>>> for the receive ring. This means that every packet recieved is not only
>>> generating an IRQ but it also stops the receive ring DMA as well until
>>> the driver re-enables it after unloading the packet.
>>
>>> This means that a number of the following errors are generated due to
>>> the receive packet FIFO overflowing due to nowhere to put packets:
>>
>>>     net eth0: Receive FIFO Overflow
>>
>>> Setting the RMCR_RNC configuration has so far been tested with an NFS
>>> root filesystem and the driver has not failed yet. It is not yet known
>>> why this is not set for R8A779x operation
>>
>>     The reason is simple: it's not set on almost all 100 Mbs devices
>> except SH7757 (and most recently added R7S72100), so this was a matter
>> of copy-paste. I've had setting this bit on at least R-Car devices on my
>> aganda for some time but couldn't get to it yet.
>>
>>> (Feedback on this issue or other testing is welcome)
>>
>>     OK, I'll try it with netperf UDP test known to generate handful of
>> the aforementioned errors, when I have time.
>
> Has anyone had time to look at this?

I gave it a try on Koelsch (it does apply to r8a7791, too, right?), and didn't
see any good or ill effects. Just using NFS root and generating some I/O,
so nothing fancy.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC] sh_eth: use RNC mode for R8A7790

[Geert Uytterhoeven]

On Mon, Apr 14, 2014 at 6:35 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Apr 14, 2014 at 2:47 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>> On 28/03/14 20:38, Sergei Shtylyov wrote:
>>> On 03/28/2014 07:46 PM, Ben Dooks wrote:
>>>> The current behaviour of the sh_eth driver is not to use the RNC bit
>>>> for the receive ring. This means that every packet recieved is not only
>>>> generating an IRQ but it also stops the receive ring DMA as well until
>>>> the driver re-enables it after unloading the packet.
>>>
>>>> This means that a number of the following errors are generated due to
>>>> the receive packet FIFO overflowing due to nowhere to put packets:
>>>
>>>>     net eth0: Receive FIFO Overflow
>>>
>>>> Setting the RMCR_RNC configuration has so far been tested with an NFS
>>>> root filesystem and the driver has not failed yet. It is not yet known
>>>> why this is not set for R8A779x operation
>>>
>>>     The reason is simple: it's not set on almost all 100 Mbs devices
>>> except SH7757 (and most recently added R7S72100), so this was a matter
>>> of copy-paste. I've had setting this bit on at least R-Car devices on my
>>> aganda for some time but couldn't get to it yet.
>>>
>>>> (Feedback on this issue or other testing is welcome)
>>>
>>>     OK, I'll try it with netperf UDP test known to generate handful of
>>> the aforementioned errors, when I have time.
>>
>> Has anyone had time to look at this?
>
> I gave it a try on Koelsch (it does apply to r8a7791, too, right?), and didn't
> see any good or ill effects. Just using NFS root and generating some I/O,
> so nothing fancy.

FWIW, I still have "renesas,no-ether-link" in the ethernet node in DT.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [RFC] sh_eth: use RNC mode for R8A7790

[Sergei Shtylyov]

Hello.

On 04/14/2014 08:48 PM, Geert Uytterhoeven wrote:

>>>>> The current behaviour of the sh_eth driver is not to use the RNC bit
>>>>> for the receive ring. This means that every packet recieved is not only
>>>>> generating an IRQ but it also stops the receive ring DMA as well until
>>>>> the driver re-enables it after unloading the packet.

>>>>> This means that a number of the following errors are generated due to
>>>>> the receive packet FIFO overflowing due to nowhere to put packets:

>>>>>      net eth0: Receive FIFO Overflow

>>>>> Setting the RMCR_RNC configuration has so far been tested with an NFS
>>>>> root filesystem and the driver has not failed yet. It is not yet known
>>>>> why this is not set for R8A779x operation

>>>>      The reason is simple: it's not set on almost all 100 Mbs devices
>>>> except SH7757 (and most recently added R7S72100), so this was a matter
>>>> of copy-paste. I've had setting this bit on at least R-Car devices on my
>>>> aganda for some time but couldn't get to it yet.

>>>>> (Feedback on this issue or other testing is welcome)

>>>>      OK, I'll try it with netperf UDP test known to generate handful of
>>>> the aforementioned errors, when I have time.

>>> Has anyone had time to look at this?

>> I gave it a try on Koelsch (it does apply to r8a7791, too, right?), and didn't
>> see any good or ill effects. Just using NFS root and generating some I/O,
>> so nothing fancy.

> FWIW, I still have "renesas,no-ether-link" in the ethernet node in DT.

    You shouldn't need it anymore if you're using recent devel branch of the 
renesas.git repo: it already has the necessary PHY driver and device tree 
changes to avoid the issue which specifying that prop fixed.

> Gr{oetje,eeting}s,

WBR, Sergei

Re: [RFC] sh_eth: use RNC mode for R8A7790

[Sergei Shtylyov]

Hello.

On 04/14/2014 04:47 PM, Ben Dooks wrote:

>>> The current behaviour of the sh_eth driver is not to use the RNC bit
>>> for the receive ring. This means that every packet recieved is not only
>>> generating an IRQ but it also stops the receive ring DMA as well until
>>> the driver re-enables it after unloading the packet.

>>> This means that a number of the following errors are generated due to
>>> the receive packet FIFO overflowing due to nowhere to put packets:

>>>     net eth0: Receive FIFO Overflow

>>> Setting the RMCR_RNC configuration has so far been tested with an NFS
>>> root filesystem and the driver has not failed yet. It is not yet known
>>> why this is not set for R8A779x operation

>>     The reason is simple: it's not set on almost all 100 Mbs devices
>> except SH7757 (and most recently added R7S72100), so this was a matter
>> of copy-paste. I've had setting this bit on at least R-Car devices on my
>> aganda for some time but couldn't get to it yet.

>>> (Feedback on this issue or other testing is welcome)

>>     OK, I'll try it with netperf UDP test known to generate handful of
>> the aforementioned errors, when I have time.

>> WBR, Sergei

> Has anyone had time to look at this?

    OK, I've finally tried netperf and couldn't get it to reproduce these 
errors on any R-Car gen2 board. I was only able to reproduce this error on a 
new R8A7791 board during NFS boot, and applying the patch seems to have 
helped. So you can add my:

Tested-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

WBR, Sergei