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 <g...@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.

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



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

Reply via email to