From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Ungerer Subject: Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC Date: Fri, 7 Dec 2018 17:12:59 +1000 Message-ID: <37dba8c4-5af2-9582-6c57-c044c7a87df6@kernel.org> References: <20181130075737.8041-1-gerg@kernel.org> <87r2f2pxpa.fsf@miraculix.mork.no> <0ef5a725-a88a-0a6e-1a69-9106cead6b65@kernel.org> <87k1kqlu80.fsf@miraculix.mork.no> <20181203140019.Horde.XrgsnGb7kljypkgiFcLqF2Z@www.vdorst.com> <3c07dbef-8e7c-8e4f-e13f-e40099e55570@phrozen.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: =?UTF-8?Q?Ren=c3=a9_van_Dorst?= , =?UTF-8?Q?Bj=c3=b8rn_Mork?= , sean.wang@mediatek.com, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com, netdev@vger.kernel.org, neil@brown.name To: John Crispin Return-path: Received: from icp-osb-irony-out2.external.iinet.net.au ([203.59.1.155]:7983 "EHLO icp-osb-irony-out2.external.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbeLGHNG (ORCPT ); Fri, 7 Dec 2018 02:13:06 -0500 In-Reply-To: <3c07dbef-8e7c-8e4f-e13f-e40099e55570@phrozen.org> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: 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 : >>> Greg Ungerer 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(ð->rx_napi))) { >>>>                 __napi_schedule(ð->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(ð->tx_napi))) { >>>>                 __napi_schedule(ð->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