[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <83aaa3b1-a2d4-8ddd-d31a-2fd6c653e3d1@wwwdotorg.org>
Date: Thu, 9 Mar 2017 13:18:11 -0700
From: Stephen Warren <swarren@...dotorg.org>
To: Thierry Reding <thierry.reding@...il.com>,
Mikko Perttunen <cyndis@...si.fi>
Cc: "David S . Miller" <davem@...emloft.net>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Alexandre Torgue <alexandre.torgue@...com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Joao Pinto <Joao.Pinto@...opsys.com>,
Alexandre Courbot <gnurou@...il.com>,
Jon Hunter <jonathanh@...dia.com>, netdev@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] net: stmmac: Program RX queue size and flow control
On 03/09/2017 12:42 PM, Thierry Reding wrote:
> On Mon, Feb 27, 2017 at 12:09:02PM +0200, Mikko Perttunen wrote:
>> On 23.02.2017 19:24, Thierry Reding wrote:
>>> From: Thierry Reding <treding@...dia.com>
>>>
>>> Program the receive queue size based on the RX FIFO size and enable
>>> hardware flow control for large FIFOs.
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
>>> @@ -252,6 +253,44 @@ static void dwmac4_dma_chan_op_mode(void __iomem *ioaddr, int txmode,
>>> mtl_rx_op |= MTL_OP_MODE_RTC_128;
>>> }
>>>
>>> + mtl_rx_op &= ~MTL_OP_MODE_RQS_MASK;
>>> + mtl_rx_op |= rqs << MTL_OP_MODE_RQS_SHIFT;
>>> +
>>> + /* enable flow control only if each channel gets 4 KiB or more FIFO */
>>> + if (rxfifosz >= 4096) {
>>> + unsigned int rfd, rfa;
>>> +
>>> + mtl_rx_op |= MTL_OP_MODE_EHFC;
>>> +
>>> + switch (rxfifosz) {
>>> + case 4096:
>>> + rfd = 0x03;
>>> + rfa = 0x01;
>>> + break;
>>> +
>>> + case 8192:
>>> + rfd = 0x06;
>>> + rfa = 0x0a;
>>> + break;
>>> +
>>> + case 16384:
>>> + rfd = 0x06;
>>> + rfa = 0x12;
>>> + break;
>>> +
>>> + default:
>>> + rfd = 0x06;
>>> + rfa = 0x1e;
>>> + break;
>>> + }
>>
>> Are these values correct? In the 4096 case, rfd > rfa, in all other cases
>> the other way around. In any case it would be useful to have a comment
>> clarifying the thresholds in bytes.
>
> I'll investigate. To be honest I simply took this from Stephen's U-Boot
> driver since that's already tested. I trust Stephen, so I didn't bother
> double-checking.
I don't recall for sure, but I think these values came directly from
either the upstream kernel (the non-stmmac driver) or NV downstream
kernel EQoS driver, and I re-used them without investigating. I'm not
even sure if the outer if() expression is true; these numbers might not
even end up being used?
Powered by blists - more mailing lists