Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC

[Greg Ungerer <gerg@kernel.org>]

Hi John,

On 4/12/18 12:02 am, John Crispin wrote:
> On 03/12/2018 15:00, René van Dorst wrote:
>> Quoting Bjørn Mork <bjorn@mork.no>:
>>> Greg Ungerer <gerg@kernel.org> writes:
>>>
>>>> The following change helped alot, but I still get some problems under
>>>> sustained load and some types of port setups. Still trying to figure
>>>> out what exactly is going on.
>>>>
>>>> --- a/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>>> +++ b/linux/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>>>> @@ -1750,8 +1750,8 @@ static irqreturn_t mtk_handle_irq_rx(int irq, void *_eth)
>>>>        if (likely(napi_schedule_prep(&eth->rx_napi))) {
>>>>                 __napi_schedule(&eth->rx_napi);
>>>> -               mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
>>>>         }
>>>> +       mtk_rx_irq_disable(eth, MTK_RX_DONE_INT);
>>>>        return IRQ_HANDLED;
>>>>  }
>>>> @@ -1762,11 +1762,53 @@ static irqreturn_t mtk_handle_irq_tx(int irq, void *_eth)
>>>>        if (likely(napi_schedule_prep(&eth->tx_napi))) {
>>>>                 __napi_schedule(&eth->tx_napi);
>>>> -               mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
>>>>         }
>>>> +       mtk_tx_irq_disable(eth, MTK_TX_DONE_INT);
>>>>        return IRQ_HANDLED;
>>>>  }
>>>
>>> Yes, sorry I didn't point to that as well.  Just to be clear:  I have no
>>> clue how this thing is actually wired up, or if you could use three
>>> interrupts on the MT7621 too. I just messed with it until I got
>>> something to work, based on Renés original idea and code.
>>
>> My idea is a just a copy of mtk_handle_irq_{rx,tx} see [1]
>> You probably want to look at the staging driver or Ubiquity source with a 3.10.x kernel [2] or padavan with 3.4.x kernel [3].
>> AFAIK mt7621 only has 1 IRQ for ethernet part.
> 
> correct there is only 1 single IRQ on mt7621

One of the main differences I see between the mainline mtk_eth_soc.c
and the older mediatek/openwrt driver is that the older driver uses
the PDMA module for TX transmission, while the mainline uses the
QDMA module. I have no documentation on the what the differences
are between the 2 (or why there is even 2 DMA engines in there?).
Can you shed any light on that?

I did a quick and dirty recode of the QDMA transmission parts of
the mainline driver code to use the PDMA engine instead. The most
immediate result is that it suffers the same IP header checksum
problem on TX packets :-(  But it also still suffers from the
same occasional TX watchdog timeout I see with only the mainline
driver and basic support of MT7621.

What I see with the TX watchdog timeouts is that there is valid
TX descriptors, but the frame engine is just not processing them.
It seems to be just sitting there idle. The CTX and DTX registers
look valid and consistent with the local last_free/next_free
pointers.

Regards
Greg