Re: [PATCH 0/3]: net: dsa: mt7530: support MT7530 in the MT7621 SoC
flat view
From: Greg Ungerer <gerg@kernel.org>
Date: 2018-12-04 07:23:19
Hi Bjorn, On 3/12/18 9:34 pm, Bjørn Mork wrote:
[ fixed Johns address - the openwrt.org email was apparently never restored? ] Greg Ungerer [off-list ref] writes:quoted
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.
Understood.
By way of progress I have found that making the single IRQ handler
look like this is better than the last patch:
static irqreturn_t mtk_handle_irq(int irq, void *_eth)
{
struct mtk_eth *eth = _eth;
irqreturn_t rc = IRQ_NONE;
if (mtk_r32(eth, MTK_PDMA_INT_MASK) & MTK_RX_DONE_INT) {
if (mtk_r32(eth, MTK_PDMA_INT_STATUS) & MTK_RX_DONE_INT)
rc = mtk_handle_irq_rx(irq, _eth);
}
if (mtk_r32(eth, MTK_QDMA_INT_MASK) & MTK_TX_DONE_INT) {
if (mtk_r32(eth, MTK_QMTK_INT_STATUS) & MTK_TX_DONE_INT)
rc = mtk_handle_irq_tx(irq, _eth);
}
return rc;
}
So not calling the RX or TX handlers if their interrupts
where not masked on. For some work loads that is quite reliable.
Flood ping through one port and out the other can get a lof of
packets through.
However I still get dev_watchdog timeouts after a while and with
more mixed packet loads. Seems like something is racing on the
TX path side.
Regards
Greg
quoted
Anyway, this really looks like the right approach to me. This driver is clearly capable of supporting the mt7621 ethernet ports. No need for the staging driver.Great! Thanks for doing this. I did make a feeble attempt at testing this with current mainline myself, but the only MT7621 board I have is using NAND flash. So I started trying to forward port the mtk-nand2 driver from OpenWrt. And failed. Probably a simple mixup while trying to adjust to the many changes in the raw NAND API between v4.14 and v.4.20. Then I optimistically attempted to use the mainline mtk-nand driver instead, assuming it would be as simple as with the mtk-eth driver. Which it wasn't, of course. I guess there are a lot of things I do not understand wrt flash and HW ECC etc... Short version: I won't be able to test the mainline mtk-eth driver with MT7621 on newer kernels before smarter people like John upgrade the OpenWrt kernel. Bjørn