Re: [OpenWrt-Devel] [PATCH] ramips: ethernet: fix to interrupt handling

[Mingyu Li]

the upstream kernel. the function mtk_napi_rx always be called if it have
packet to receive. it doesn't check status register.
but on openwrt code. check the status register first. then call fe_poll_rx.
if you clear status register. fe_poll_rx will will not be called next time.

Rosen Penev  於 2019年10月30日 週三 上午12:51寫道：
>
> On Wed, Mar 6, 2019 at 12:37 AM Mingyu Li  wrote:
> >
> > the original code use status register to keep there still have some
> > pkts in buffer.
> > need next napi call to receive it.
> >
> > if 128 packets in buffer. you clear status first. because napi max
> > handle 64 packets in buffer.
> > so 64 packets need to handle in next napi poll. if no new packet
> > comming. the status register will not set.
> > so fe_poll function will not call fe_poll_tx or fe_poll_rx. that would
> > be a problem.
> >
> > the status register also use to control napi interrupt enable. must
> > make sure no packets need to
> > handle then enable interrupt.
> I took a look at this again. The upstream kernel driver does the same
> as this patch: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/mediatek/mtk_eth_soc.c?h=v4.14.151#n1189
> >
> > Rosen Penev  於 2019年3月6日 週三 下午12:08寫道：
> > >
> > > From: NeilBrown 
> > >
> > > The current code acknowledged interrupts *after* polling.
> > > This is the wrong way around, and could cause an interrupt to
> > > be missed.
> > > This is not likely to be fatal as another packet, and so another
> > > interrupt, should come along soon.  But maybe it is causing
> > > problems, so let's fix it anyway.
> > >
> > > Signed-off-by: NeilBrown 
> > > Signed-off-by: Rosen Penev 
> > > ---
> > >  .../drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 11 +--
> > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > >
> > > diff --git 
> > > a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > >  
> > > b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > index e0bc0ab818..2e0c8f94ca 100644
> > > --- 
> > > a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > +++ 
> > > b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > @@ -876,6 +876,8 @@ static int fe_poll_rx(struct napi_struct *napi, int 
> > > budget,
> > > struct fe_rx_dma *rxd, trxd;
> > > int done = 0, pad;
> > >
> > > +   fe_reg_w32(rx_intr, FE_REG_FE_INT_STATUS);
> > > +
> > > if (netdev->features & NETIF_F_RXCSUM)
> > > checksum_bit = soc->checksum_bit;
> > > else
> > > @@ -963,9 +965,6 @@ release_desc:
> > > done++;
> > > }
> > >
> > > -   if (done < budget)
> > > -   fe_reg_w32(rx_intr, FE_REG_FE_INT_STATUS);
> > > -
> > > return done;
> > >  }
> > >
> > > @@ -981,6 +980,8 @@ static int fe_poll_tx(struct fe_priv *priv, int 
> > > budget, u32 tx_intr,
> > > u32 idx, hwidx;
> > > struct fe_tx_ring *ring = >tx_ring;
> > >
> > > +   fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
> > > +
> > > idx = ring->tx_free_idx;
> > > hwidx = fe_reg_r32(FE_REG_TX_DTX_IDX0);
> > >
> > > @@ -1004,9 +1005,7 @@ static int fe_poll_tx(struct fe_priv *priv, int 
> > > budget, u32 tx_intr,
> > > if (idx == hwidx) {
> > > /* read hw index again make sure no new tx packet */
> > > hwidx = fe_reg_r32(FE_REG_TX_DTX_IDX0);
> > > -   if (idx == hwidx)
> > > -   fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
> > > -   else
> > > +   if (idx != hwidx)
> > > *tx_again = 1;
> > > } else {
> > > *tx_again = 1;
> > > --
> > > 2.17.1
> > >
> > >
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: ethernet: fix to interrupt handling

[Mingyu Li]

the original code use status register to keep there still have some
pkts in buffer.
need next napi call to receive it.

if 128 packets in buffer. you clear status first. because napi max
handle 64 packets in buffer.
so 64 packets need to handle in next napi poll. if no new packet
comming. the status register will not set.
so fe_poll function will not call fe_poll_tx or fe_poll_rx. that would
be a problem.

the status register also use to control napi interrupt enable. must
make sure no packets need to
handle then enable interrupt.

Rosen Penev  於 2019年3月6日 週三 下午12:08寫道：
>
> From: NeilBrown 
>
> The current code acknowledged interrupts *after* polling.
> This is the wrong way around, and could cause an interrupt to
> be missed.
> This is not likely to be fatal as another packet, and so another
> interrupt, should come along soon.  But maybe it is causing
> problems, so let's fix it anyway.
>
> Signed-off-by: NeilBrown 
> Signed-off-by: Rosen Penev 
> ---
>  .../drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git 
> a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
> b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index e0bc0ab818..2e0c8f94ca 100644
> --- 
> a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ 
> b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -876,6 +876,8 @@ static int fe_poll_rx(struct napi_struct *napi, int 
> budget,
> struct fe_rx_dma *rxd, trxd;
> int done = 0, pad;
>
> +   fe_reg_w32(rx_intr, FE_REG_FE_INT_STATUS);
> +
> if (netdev->features & NETIF_F_RXCSUM)
> checksum_bit = soc->checksum_bit;
> else
> @@ -963,9 +965,6 @@ release_desc:
> done++;
> }
>
> -   if (done < budget)
> -   fe_reg_w32(rx_intr, FE_REG_FE_INT_STATUS);
> -
> return done;
>  }
>
> @@ -981,6 +980,8 @@ static int fe_poll_tx(struct fe_priv *priv, int budget, 
> u32 tx_intr,
> u32 idx, hwidx;
> struct fe_tx_ring *ring = >tx_ring;
>
> +   fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
> +
> idx = ring->tx_free_idx;
> hwidx = fe_reg_r32(FE_REG_TX_DTX_IDX0);
>
> @@ -1004,9 +1005,7 @@ static int fe_poll_tx(struct fe_priv *priv, int budget, 
> u32 tx_intr,
> if (idx == hwidx) {
> /* read hw index again make sure no new tx packet */
> hwidx = fe_reg_r32(FE_REG_TX_DTX_IDX0);
> -   if (idx == hwidx)
> -   fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
> -   else
> +   if (idx != hwidx)
> *tx_again = 1;
> } else {
> *tx_again = 1;
> --
> 2.17.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 8/8] ramips: update dtsi files to support second spi device

[Mingyu Li]

Dear Sir.

you need to modify kernel file at "arch/mips/ralink/rt305x.c"
add the code below.

ralink_clk_add("1b00.spi", sys_rate);
+ralink_clk_add("1b40.spi", sys_rate);
ralink_clk_add("1100.timer", wdt_rate);

please let me know if the second spi works. if works
i will commit a patch about the second spi clock include
all other targets.
thanks.

Best Regards.

2015-11-23 3:08 GMT+08:00 John Crispin :

>
>
> On 22/11/2015 16:15, Álvaro Fernández Rojas wrote:
> > Hello guys,
> >
> > I've just tested this patch on my VoCore after it was applied on r47580.
> > I had to make the following changes:
> >
> https://github.com/openwrt-es/openwrt/commit/e040cf00441e973978a6c168b346b13e33f37853
> >
> >
> > However, I'm getting the following error: "spi-rt2880 1b40.spi:
> > unable to get SYS clock"
> > https://gist.github.com/Noltari/7629d3384fe421517336
> >
> > Did anyone actually test this with both spi nodes enabled?
> >
> > Regards,
> > Álvaro.
>
> i only compile tested it.
>
> John
>
> >
> > El 08/10/2015 a las 16:16, Michael Lee escribió:
> >> Signed-off-by: Michael Lee 
> >> ---
> >>   target/linux/ramips/dts/mt7620a.dtsi   |  32 +-
> >>   target/linux/ramips/dts/mt7620n.dtsi   |  32 +-
> >>   target/linux/ramips/dts/rt3050.dtsi|   6 +-
> >>   target/linux/ramips/dts/rt3352.dtsi|  31 +-
> >>   target/linux/ramips/dts/rt3883.dtsi|  25 +-
> >>   target/linux/ramips/dts/rt5350.dtsi|  29 +-
> >>   .../0051-rt5350-spi-second-device.patch| 368
> >> -
> >>   7 files changed, 143 insertions(+), 380 deletions(-)
> >>   delete mode 100644
> >> target/linux/ramips/patches-3.18/0051-rt5350-spi-second-device.patch
> >>
> >> diff --git a/target/linux/ramips/dts/mt7620a.dtsi
> >> b/target/linux/ramips/dts/mt7620a.dtsi
> >> index 026e745..448df75 100644
> >> --- a/target/linux/ramips/dts/mt7620a.dtsi
> >> +++ b/target/linux/ramips/dts/mt7620a.dtsi
> >> @@ -20,6 +20,11 @@
> >>   compatible = "mti,cpu-interrupt-controller";
> >>   };
> >>   +aliases {
> >> +spi0 = 
> >> +spi1 = 
> >> +};
> >> +
> >>   palmbus@1000 {
> >>   compatible = "palmbus";
> >>   reg = <0x1000 0x20>;
> >> @@ -202,9 +207,9 @@
> >>   status = "disabled";
> >>   };
> >>   -spi@b00 {
> >> +spi0: spi@b00 {
> >>   compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi";
> >> -reg = <0xb00 0x100>;
> >> +reg = <0xb00 0x40>;
> >> resets = < 18>;
> >>   reset-names = "spi";
> >> @@ -218,6 +223,22 @@
> >>   pinctrl-0 = <_pins>;
> >>   };
> >>   +spi1: spi@b40 {
> >> +compatible = "ralink,rt2880-spi";
> >> +reg = <0xb40 0x60>;
> >> +
> >> +resets = < 18>;
> >> +reset-names = "spi";
> >> +
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +
> >> +status = "disabled";
> >> +
> >> +pinctrl-names = "default";
> >> +pinctrl-0 = <_cs1>;
> >> +};
> >> +
> >>   uartlite@c00 {
> >>   compatible = "ralink,mt7620a-uart",
> >> "ralink,rt2880-uart", "ns16550a";
> >>   reg = <0xc00 0x100>;
> >> @@ -305,6 +326,13 @@
> >>   };
> >>   };
> >>   +spi_cs1: spi1 {
> >> +spi1 {
> >> +ralink,group = "spi_cs1";
> >> +ralink,function = "spi_cs1";
> >> +};
> >> +};
> >> +
> >>   i2c_pins: i2c {
> >>   i2c {
> >>   ralink,group = "i2c";
> >> diff --git a/target/linux/ramips/dts/mt7620n.dtsi
> >> b/target/linux/ramips/dts/mt7620n.dtsi
> >> index b1586ec..a3132b8 100644
> >> --- a/target/linux/ramips/dts/mt7620n.dtsi
> >> +++ b/target/linux/ramips/dts/mt7620n.dtsi
> >> @@ -20,6 +20,11 @@
> >>   compatible = "mti,cpu-interrupt-controller";
> >>   };
> >>   +aliases {
> >> +spi0 = 
> >> +spi1 = 
> >> +};
> >> +
> >>   palmbus@1000 {
> >>   compatible = "palmbus";
> >>   reg = <0x1000 0x20>;
> >> @@ -154,9 +159,9 @@
> >>   status = "disabled";
> >>   };
> >>   -spi@b00 {
> >> +spi0: spi@b00 {
> >>   compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi";
> >> -reg = <0xb00 0x100>;
> >> +reg = <0xb00 0x40>;
> >> resets = < 18>;
> >>   reset-names = "spi";
> >> @@ -170,6 +175,22 @@
> >>   pinctrl-0 = <_pins>;
> >>   };
> >>   +spi1: spi@b40 {
> >> +compatible = "ralink,rt2880-spi";
> >> +reg = <0xb40 0x60>;
> >> +
> >> +resets = < 18>;
> >> +reset-names = "spi";
> >> +
> >> +

Re: [OpenWrt-Devel] [PATCH 2/8] ramips: remove rt2880 spi lock and clean bit operation

[Mingyu Li]

Hi John.

i check the code which functions need read/write register.
3 functions (prepare_message, set_cs, transfer_one) are used
at same function __spi_pump_messages at spi.c.

the __spi_pump_message is protected by spi_master->queue_lock
this make sure spi device operation is serialized.

the spi bus is protected by spi_master->bus_lock_spinlock. you can
found it at spi_async function. it make sure only one spi device work
on the same spi bus.
so the 3 functions don't have lock problem.

about the setup function. it maybe be called by user space to setup
a new spi device. but it will not affect other spi device. because it just
disable the new spi device by useing cs pin.

so i think it is save to remove the lock protect.

the most important is the lock on probe function must be wrong.
because it only call spin_lock_irqsave. but not call spin_unlock_irqrestore.

2015-10-26 22:26 GMT+08:00 John Crispin :

> Hi Michael,
>
> while merging the series i stumbled across this patch. to me this looks
> wrong.
>
> rather than removing the locking i think we should add more to
> rt2880_spi_read and rt2880_spi_write.
>
> i'll merge the other 7 patches just now if they apply without 2/8
>
>
> John
>
> On 08/10/2015 16:16, Michael Lee wrote:
> > Signed-off-by: Michael Lee 
> > ---
> >  ...0050-SPI-ralink-add-Ralink-SoC-spi-driver.patch | 23
> +-
> >  1 file changed, 5 insertions(+), 18 deletions(-)
> >
> > diff --git
> a/target/linux/ramips/patches-3.18/0050-SPI-ralink-add-Ralink-SoC-spi-driver.patch
> b/target/linux/ramips/patches-3.18/0050-SPI-ralink-add-Ralink-SoC-spi-driver.patch
> > index ca04a17..d6a462c 100644
> > ---
> a/target/linux/ramips/patches-3.18/0050-SPI-ralink-add-Ralink-SoC-spi-driver.patch
> > +++
> b/target/linux/ramips/patches-3.18/0050-SPI-ralink-add-Ralink-SoC-spi-driver.patch
> > @@ -41,7 +41,7 @@ Acked-by: John Crispin 
> >   spi-s3c24xx-hw-$(CONFIG_SPI_S3C24XX_FIQ) += spi-s3c24xx-fiq.o
> >  --- /dev/null
> >  +++ b/drivers/spi/spi-rt2880.c
> > -@@ -0,0 +1,493 @@
> > +@@ -0,0 +1,480 @@
> >  +/*
> >  + * spi-rt2880.c -- Ralink RT288x/RT305x SPI controller driver
> >  + *
> > @@ -174,7 +174,6 @@ Acked-by: John Crispin 
> >  +unsigned intsys_freq;
> >  +unsigned intspeed;
> >  +struct clk  *clk;
> > -+spinlock_t  lock;
> >  +};
> >  +
> >  +static inline struct rt2880_spi *spidev_to_rt2880_spi(struct
> spi_device *spi)
> > @@ -187,7 +186,8 @@ Acked-by: John Crispin 
> >  +return ioread32(rs->base + reg);
> >  +}
> >  +
> > -+static inline void rt2880_spi_write(struct rt2880_spi *rs, u32 reg,
> u32 val)
> > ++static inline void rt2880_spi_write(struct rt2880_spi *rs, u32 reg,
> > ++const u32 val)
> >  +{
> >  +iowrite32(val, rs->base + reg);
> >  +}
> > @@ -195,27 +195,15 @@ Acked-by: John Crispin 
> >  +static inline void rt2880_spi_setbits(struct rt2880_spi *rs, u32 reg,
> u32 mask)
> >  +{
> >  +void __iomem *addr = rs->base + reg;
> > -+unsigned long flags;
> > -+u32 val;
> >  +
> > -+spin_lock_irqsave(>lock, flags);
> > -+val = ioread32(addr);
> > -+val |= mask;
> > -+iowrite32(val, addr);
> > -+spin_unlock_irqrestore(>lock, flags);
> > ++iowrite32((ioread32(addr) | mask), addr);
> >  +}
> >  +
> >  +static inline void rt2880_spi_clrbits(struct rt2880_spi *rs, u32 reg,
> u32 mask)
> >  +{
> >  +void __iomem *addr = rs->base + reg;
> > -+unsigned long flags;
> > -+u32 val;
> >  +
> > -+spin_lock_irqsave(>lock, flags);
> > -+val = ioread32(addr);
> > -+val &= ~mask;
> > -+iowrite32(val, addr);
> > -+spin_unlock_irqrestore(>lock, flags);
> > ++iowrite32((ioread32(addr) & ~mask), addr);
> >  +}
> >  +
> >  +static int rt2880_spi_baudrate_set(struct spi_device *spi, unsigned
> int speed)
> > @@ -488,7 +476,6 @@ Acked-by: John Crispin 
> >  +rs->master = master;
> >  +rs->sys_freq = clk_get_rate(rs->clk);
> >  +dev_dbg(>dev, "sys_freq: %u\n", rs->sys_freq);
> > -+spin_lock_irqsave(>lock, flags);
> >  +
> >  +device_reset(>dev);
> >  +
> >
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 6/8] ramips: improve mt7621 spi chip select

[Mingyu Li]

i have mention "add debug info" on comment. or you suggest me
move the debug info into another patch.

about num_chipselect. now we should use gpio pin as chip select
pin. so there is no limit on num_chipselect. we can connect more
spi devices by using gpio pin as chip select pin. you can check
spi_set_cs function.

2015-10-14 12:24 GMT+08:00 John Crispin :

> 2 comments inline
>
> On 11/10/2015 05:54, Michael Lee wrote:
> > * use chip select register to control chip select function instead of
> >   use chip select polarity
> > * should support use gpio as cs pin
> > * deselected the spi device when setup and add debug info
> >
> > Signed-off-by: Michael Lee 
> > ---
> >  ...0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch | 95
> --
> >  1 file changed, 68 insertions(+), 27 deletions(-)
> >
> > diff --git
> a/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> b/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> > index d1067ea..1b2476c 100644
> > ---
> a/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> > +++
> b/target/linux/ramips/patches-3.18/0061-SPI-ralink-add-mt7621-SoC-spi-driver.patch
> > @@ -25,7 +25,7 @@
> >   obj-$(CONFIG_SPI_OC_TINY)   += spi-oc-tiny.o
> >  --- /dev/null
> >  +++ b/drivers/spi/spi-mt7621.c
> > -@@ -0,0 +1,582 @@
> > +@@ -0,0 +1,623 @@
> >  +/*
> >  + * spi-mt7621.c -- MediaTek MT7621 SPI controller driver
> >  + *
> > @@ -53,6 +53,7 @@
> >  +#include 
> >  +#include 
> >  +#include 
> > ++#include 
> >  +
> >  +#include 
> >  +
> > @@ -208,30 +209,26 @@
> >  +return (prescale << SPIMASTER_CLKSEL_OFFSET);
> >  +}
> >  +
> > -+static void mt7621_spi_reset(struct mt7621_spi *rs, int duplex)
> > ++static void mt7621_spi_set_cs(struct spi_device *spi, bool enable)
> >  +{
> > -+u32 master = mt7621_spi_read(rs, MT7621_SPI_MASTER);
> > -+
> > -+master |= 7 << 29;
> > -+master |= 1 << 2;
> > -+if (duplex)
> > -+master |= 1 << 10;
> > -+else
> > -+master &= ~(1 << 10);
> > ++struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> > ++u32 reg;
> >  +
> > -+mt7621_spi_write(rs, MT7621_SPI_MASTER, master);
> > -+}
> > ++if (spi->mode & SPI_CS_HIGH)
> > ++enable = !enable;
> > ++enable = !enable;
> >  +
> > -+static void mt7621_spi_set_cs(struct spi_device *spi, int enable)
> > -+{
> > -+struct mt7621_spi *rs = spidev_to_mt7621_spi(spi);
> > -+int cs = spi->chip_select;
> > -+u32 polar = 0;
> > ++reg = mt7621_spi_read(rs, MT7621_SPI_MASTER);
> > ++reg &= ~(SPIMASTER_CS_MASK << SPIMASTER_CS_OFFSET);
> >  +
> > -+mt7621_spi_reset(rs, cs);
> >  +if (enable)
> > -+polar = BIT(cs);
> > -+mt7621_spi_write(rs, MT7621_SPI_POLAR, polar);
> > ++reg |= (spi->chip_select << SPIMASTER_CS_OFFSET);
> > ++else {
> > ++/* when disable just enable cs 8 instead */
> > ++reg |= (SPIMASTER_CS_MASK << SPIMASTER_CS_OFFSET);
> > ++}
> > ++
> > ++mt7621_spi_write(rs, MT7621_SPI_MASTER, reg);
> >  +}
> >  +
> >  +static inline int mt7621_spi_wait_ready(struct mt7621_spi *rs, int len)
> > @@ -247,6 +244,47 @@
> >  +return -ETIMEDOUT;
> >  +}
> >  +
> > ++static void mt7621_dump_reg(struct spi_master *master, const char
> *func)
> > ++{
> > ++struct mt7621_spi *rs = spi_master_get_devdata(master);
> > ++
> > ++dev_dbg(>dev, "%s trans: %08x, opcode: %08x, data0: %08x, "
> > ++"data1: %08x, data2: %08x, data3: %08x, " \
> > ++"data4: %08x, data5: %08x, data6: %08x, " \
> > ++"data7: %08x, master: %08x, morebuf: %08x, " \
> > ++"qctl: %08x, status: %08x, polar: %08x, " \
> > ++"space: %08x\n",
> > ++func,
> > ++mt7621_spi_read(rs, MT7621_SPI_TRANS),
> > ++mt7621_spi_read(rs, MT7621_SPI_OPCODE),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 4),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 8),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 12),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 16),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 20),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 24),
> > ++mt7621_spi_read(rs, MT7621_SPI_DATA0 + 28),
> > ++mt7621_spi_read(rs, MT7621_SPI_MASTER),
> > ++mt7621_spi_read(rs, MT7621_SPI_MOREBUF),
> > ++mt7621_spi_read(rs, MT7621_SPI_QUEUE_CTL),
> > ++mt7621_spi_read(rs, MT7621_SPI_STATUS),
> > ++mt7621_spi_read(rs, MT7621_SPI_POLAR),
> > ++mt7621_spi_read(rs, 

Re: [OpenWrt-Devel] [PATCH 5/7] ramips: fix mt7621 cpu clock speed. set spi clock to system clock

[Mingyu Li]

according to mtk sdk 4300 at kernel version linux-2.6.36.x
at 40Mhz Xtal it use 20 not 40.

#elif defined (CONFIG_RALINK_MT7621)
case 0:
reg = (*(volatile u32 *)(RALINK_SYSCTL_BASE + 0x44));
cpu_fdiv = ((reg >> 8) & 0x1F);
cpu_ffrac = (reg & 0x1F);
mips_cpu_feq = (500 * cpu_ffrac / cpu_fdiv) * 1000 * 1000;
break;
case 1: //CPU PLL
reg = (*(volatile u32 *)(RALINK_MEMCTRL_BASE + 0x648));
fbdiv = ((reg >> 4) & 0x7F) + 1;
reg = (*(volatile u32 *)(RALINK_SYSCTL_BASE + 0x10));
reg = (reg >> 6) & 0x7;
if(reg >= 6) { //25Mhz Xtal
mips_cpu_feq = 25 * fbdiv * 1000 * 1000;
} else if(reg >=3) { //40Mhz Xtal
mips_cpu_feq = 20 * fbdiv * 1000 * 1000;
} else { // 20Mhz Xtal
/* TODO */
}
break;
#elif defined (CONFIG_RALINK_MT7628)

2015-10-05 18:11 GMT+08:00 John Crispin :

> Hi,
>
> comments inline,
>
> On 22/09/2015 15:26, Michael Lee wrote:
> > From: michael lee 
> >
> > spi clock is the same as system clock measured by logic analyzer.
> >
> > Signed-off-by: Michael Lee 
> > ---
> >  .../0012-MIPS-ralink-add-MT7621-support.patch  | 29
> +-
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git
> a/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
> b/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
> > index 23d3268..bb4a8e1 100644
> > ---
> a/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
> > +++
> b/target/linux/ramips/patches-3.18/0012-MIPS-ralink-add-MT7621-support.patch
> > @@ -520,7 +520,7 @@ Signed-off-by: John Crispin 
> >  +}
> >  --- /dev/null
> >  +++ b/arch/mips/ralink/mt7621.c
> > -@@ -0,0 +1,209 @@
> > +@@ -0,0 +1,226 @@
> >  +/*
> >  + * This program is free software; you can redistribute it and/or
> modify it
> >  + * under the terms of the GNU General Public License version 2 as
> published
> > @@ -553,6 +553,8 @@ Signed-off-by: John Crispin 
> >  +#define SYSC_REG_CUR_CLK_STS0x44
> >  +#define CPU_CLK_SEL (BIT(30) | BIT(31))
> >  +
> > ++#define MEMC_REG_BASE   0x5000
> > ++
> >  +#define MT7621_GPIO_MODE_UART1  1
> >  +#define MT7621_GPIO_MODE_I2C2
> >  +#define MT7621_GPIO_MODE_UART3_MASK 0x3
> > @@ -645,7 +647,7 @@ Signed-off-by: John Crispin 
> >  +int fbdiv = 0;
> >  +u32 clk_sts, syscfg;
> >  +u8 clk_sel = 0, xtal_mode;
> > -+u32 cpu_clk;
> > ++u32 cpu_clk, sys_clk;
> >  +
> >  +if ((rt_sysc_r32(SYSC_REG_CPLL_CLKCFG0) & CPU_CLK_SEL) != 0)
> >  +clk_sel = 1;
> > @@ -656,24 +658,39 @@ Signed-off-by: John Crispin 
> >  +cpu_fdiv = ((clk_sts >> 8) & 0x1F);
> >  +cpu_ffrac = (clk_sts & 0x1F);
> >  +cpu_clk = (500 * cpu_ffrac / cpu_fdiv) * 1000 * 1000;
> > ++if (((clk_sts >> 16) & 0x7) == 3)
> > ++sys_clk = cpu_clk / 3;
> > ++else
> > ++sys_clk = cpu_clk / 4;
> >  +break;
> >  +
> >  +case 1:
> > -+fbdiv = ((rt_sysc_r32(0x648) >> 4) & 0x7F) + 1;
> > ++fbdiv = ((rt_sysc_r32(MEMC_REG_BASE + 0x648) >> 4) & 0x7F)
> + 1;
> >  +syscfg = rt_sysc_r32(SYSC_REG_SYSCFG);
> >  +xtal_mode = (syscfg >> 6) & 0x7;
> >  +if(xtal_mode >= 6) { //25Mhz Xtal
> >  +cpu_clk = 25 * fbdiv * 1000 * 1000;
> >  +} else if(xtal_mode >=3) { //40Mhz Xtal
> > -+cpu_clk = 40 * fbdiv * 1000 * 1000;
> > ++cpu_clk = 20 * fbdiv * 1000 * 1000;
>
> this looks wrong. can you confirm that this is intentional and not a typo ?
>
>
>
> >  +} else { // 20Mhz Xtal
> >  +cpu_clk = 20 * fbdiv * 1000 * 1000;
> >  +}
> > ++if (syscfg & BIT(5))
> > ++sys_clk = cpu_clk / 4;
> > ++else
> > ++sys_clk = cpu_clk / 3;
> >  +break;
> >  +}
> > -+cpu_clk = 88000;
> > ++
> > ++#define RFMT(label) label ":%u.%03uMHz "
> > ++#define RINT(x) ((x) / 100)
> > ++#define RFRAC(x)(((x) / 1000) % 1000)
> > ++pr_debug(RFMT("CPU") RFMT("SYS"),
> > ++ RINT(cpu_clk), RFRAC(cpu_clk),
> > ++ RINT(sys_clk), RFRAC(sys_clk));
> > ++
> >  +ralink_clk_add("cpu", cpu_clk);
> > -+ralink_clk_add("1e000b00.spi", 5000);
> > ++ralink_clk_add("1e000b00.spi", sys_clk);
> >  +ralink_clk_add("1e000c00.uartlite", 5000);
> >  +ralink_clk_add("1e000d00.uart", 5000);
> >  +}
> >
>

Re: [OpenWrt-Devel] [PATCH] [ 4/5] ramips: add xmit_more support

[Mingyu Li]

this feature i reference tg3.c driver at function tg3_start_xmit.
it says therer is a small possibility that start_xmit will miss it
and cause the queue to be stopped forever.

below is the tg3 drivers code
=== function tg3_tx ===
tnapi-tx_cons = sw_idx;

/* Need to make the tx_cons update visible to tg3_start_xmit()
 * before checking for netif_queue_stopped().  Without the
 * memory barrier, there is a small possibility that
tg3_start_xmit()
 * will miss it and cause the queue to be stopped forever.
 */
smp_mb();

if (unlikely(netif_tx_queue_stopped(txq) 
 (tg3_tx_avail(tnapi)  TG3_TX_WAKEUP_THRESH(tnapi {
__netif_tx_lock(txq, smp_processor_id());
if (netif_tx_queue_stopped(txq) 
(tg3_tx_avail(tnapi)  TG3_TX_WAKEUP_THRESH(tnapi)))
netif_tx_wake_queue(txq);
__netif_tx_unlock(txq);
}

=== tg3_start_xmit ===
budget = tg3_tx_avail(tnapi);

/* We are running in BH disabled context with netif_tx_lock
 * and TX reclaim runs via tp-napi.poll inside of a software
 * interrupt.  Furthermore, IRQ processing runs lockless so we have
 * no IRQ context deadlocks to worry about either.  Rejoice!
 */
if (unlikely(budget = (skb_shinfo(skb)-nr_frags + 1))) {
if (!netif_tx_queue_stopped(txq)) {
netif_tx_stop_queue(txq);

/* This is a hard error, log it. */
netdev_err(dev,
   BUG! Tx Ring full when queue awake!\n);
}
return NETDEV_TX_BUSY;
}


2015-06-05 16:40 GMT+08:00 Felix Fietkau n...@openwrt.org:

 On 2015-06-02 15:06, michael lee wrote:
  use pktgen to verify on rt3662. can improve transmit rate.
  pkt_size 1500
  burst 1 : 807Mb/sec
  burst 8 : 984Mb/sec
 
  pkt_size 60
  burst 1 : 57Mb/sec
  burst 8 : 236Mb/sec
 
  Signed-off-by: michael lee igv...@gmail.com
  ---
   .../drivers/net/ethernet/ralink/ralink_soc_eth.c   | 51
 +-
   .../drivers/net/ethernet/ralink/ralink_soc_eth.h   |  2 +
   2 files changed, 33 insertions(+), 20 deletions(-)
 
  diff --git
 a/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
 b/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
  index b2304bb..4b39825 100644
  ---
 a/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
  +++
 b/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
  @@ -337,6 +337,8 @@ static int fe_alloc_tx(struct fe_priv *priv)
struct fe_tx_ring *ring = priv-tx_ring;
 
ring-tx_free_idx = 0;
  + ring-tx_next_idx = 0;
  + ring-tx_thresh = max((unsigned long)ring-tx_ring_size  2,
 MAX_SKB_FRAGS);
 
ring-tx_buf = kcalloc(ring-tx_ring_size, sizeof(*ring-tx_buf),
GFP_KERNEL);
  @@ -525,8 +527,16 @@ static int fe_vlan_rx_kill_vid(struct net_device
 *dev,
return 0;
   }
 
  +static inline u32 fe_empty_txd(struct fe_tx_ring *ring)
  +{
  + barrier();
 What is this barrier for?

  + return (u32)(ring-tx_ring_size -
  + ((ring-tx_next_idx - ring-tx_free_idx) 
  +  (ring-tx_ring_size - 1)));
  +}
  +
   static int fe_tx_map_dma(struct sk_buff *skb, struct net_device *dev,
  - int idx, int tx_num, struct fe_tx_ring *ring)
  + int tx_num, struct fe_tx_ring *ring)
   {
struct fe_priv *priv = netdev_priv(dev);
struct skb_frag_struct *frag;
  @@ -649,14 +659,22 @@ static int fe_tx_map_dma(struct sk_buff *skb,
 struct net_device *dev,
netdev_sent_queue(dev, skb-len);
skb_tx_timestamp(skb);
 
  - j = NEXT_TX_DESP_IDX(j);
  + ring-tx_next_idx = NEXT_TX_DESP_IDX(j);
wmb();
  - fe_reg_w32(j, FE_REG_TX_CTX_IDX0);
  + if (unlikely(fe_empty_txd(ring) = ring-tx_thresh)) {
  + netif_stop_queue(dev);
  + smp_mb();
  + if (unlikely(fe_empty_txd(ring)  ring-tx_thresh))
  + netif_wake_queue(dev);
 Why do that queue wake check here, when it's already being done during
 tx cleanup.

  + }
  +
  + if (netif_xmit_stopped(netdev_get_tx_queue(dev, 0)) ||
 !skb-xmit_more)
  + fe_reg_w32(ring-tx_next_idx, FE_REG_TX_CTX_IDX0);
 
return 0;
 
   err_dma:
  - j = idx;
  + j = ring-tx_next_idx;
for (i = 0; i  tx_num; i++) {
ptxd = ring-tx_dma[j];
tx_buf = ring-tx_buf[j];

 - Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] AsiaRF AWM002 (ramips) USB and reboot broken at r44044

[Mingyu Li]

Dear Sir.

the fe_reset only used to reset ethernet and switch driver.
i think your problem is the old code is wrong.
at ethernet driver(soc_rt305x.c) it just clean all reset bit (enable all
functions. usb?).
but the new code only reset and enable ethernet and switch block.
you can see the diff as below.

 static void rt5350_fe_reset(void)
 {
-   rt_sysc_w32(RT305X_RESET_FE | RT305X_RESET_ESW,
SYSC_REG_RESET_CTRL);
-   rt_sysc_w32(0, SYSC_REG_RESET_CTRL);
+   fe_reset(RT305X_RESET_FE | RT305X_RESET_ESW);
 }

+void fe_reset(u32 reset_bits)
+{
+   u32 t;
+
+   t = rt_sysc_r32(SYSC_REG_RSTCTRL);
+   t |= reset_bits;
+   rt_sysc_w32(t , SYSC_REG_RSTCTRL);
+   udelay(10);
+
+   t = ~reset_bits;
+   rt_sysc_w32(t, SYSC_REG_RSTCTRL);
+   udelay(10);
+}

Best Regards.

2015-02-03 13:44 GMT+08:00 Russell Senior russ...@personaltelco.net:

  Russell == Russell Senior russ...@personaltelco.net writes:

 Russell I just wanted to give a heads up that I built trunk r44245 last
 Russell night and discovered two problems: reboot no longer works, and
 Russell USB fails to enumerate a usb-serial device that worked
 Russell previously (specifically a pl2303).  To successfully reset, a
 Russell power cycle is required.  These problems were not evident the
 Russell last time I built, about 3 weeks ago, r43960.  The lsmod output
 Russell is nearly identical between working/not-working (with some
 Russell minor fuzz in a few module sizes).

 Russell I'm planning to try bisecting this, but if someone knows the
 Russell problem and beats me to it, I'd be grateful.  Bisecting is
 Russell powerful but somewhat tedious. ;-)

 I bisected the problem.  It appears the bad commit is r44044 (r44043 is
 good).  The reset and usb problems appear at the same commit.

 commit fb038c46afa40edbd37eb9a93468312b287c5aa7
 Author: nbd nbd@3c298f89-4303-0410-b956-a3cf2f4a3e73
 Date:   Sun Jan 18 20:17:07 2015 +

 ralink: use fe_reset to control all reset

 Signed-off-by: michael lee igv...@gmail.com

 git-svn-id: svn://svn.openwrt.org/openwrt/trunk@44044
 3c298f89-4303-0410-b956-a3cf2f4a3e73



 --
 Russell Senior, President
 russ...@personaltelco.net

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Ralink ethernet update

[Mingyu Li]

i checkout the latest code and rebuild for rt-n15
only test 3 times lan to wan tcp performance 60 seconds one thread

netperf version 2.6.0
116.33, 116.20, 102.84 (10^6bits/sec)

iperf 2.0.5
120, 116, 113 (Mbits/sec)

iperf 3.0.7
113, 124, 121 (Mbits/sec)

2014-10-30 18:35 GMT+08:00 Paul Fertser fercer...@gmail.com:

 John Crispin blo...@openwrt.org writes:

  I have RT5350 for testing (Hame MPR-A1), not MT7620/MT7530, I'm not
  sure if the same codepath is used, but it looks like not? I will
  probably be able to do whatever testing you need over the weekend.
 
 
  ok, so on rt5350 tcp fails if vlans are disbaled ?

 As far as I can tell, yes, at least it was the case when I was
 submitting [1].

 [1] http://patchwork.openwrt.org/patch/6085/
 --
 Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
 mailto:fercer...@gmail.com
 ___
 openwrt-devel mailing list
 openwrt-devel@lists.openwrt.org
 https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Ralink ethernet update

[Mingyu Li]

on rt2880 i also use rt-n15. the performance on rt2880 seeks unstable.
sometime low. sometime high. i also don't know why.
others target are more stable. so the maximum is 12x i got.
by datasheet it support tx/rx checksum offload. but ralink sdk disable it.
so i also disable it. so the performanc is not so good.
i use netperf for test.

on mt7620 i only have fast ethernet ports work version. so the maximum is
94.
i also have gigabit port device. but the switch can't work. so i can't test.

so i focus on rt3662 device which with gigabit support.
the most improve is tcp. the udp improve not so much.

you can use ethtool to enable/disable some offload features.
this improve on driver support SG so GSO is eanble too.
also let GRO work by add rxvlan offload(by software).

2014-10-30 8:58 GMT+08:00 Roman Yeryomin leroi.li...@gmail.com:

 On 29 October 2014 21:48, John Crispin blo...@openwrt.org wrote:
  Hi,
 
  i just pushed a huge update to the ralink ethernet driver. i want to
  thank Mingyu for taking so much time to fix all these details in the
  driver. There has already been a lot of testing in the background. I
  expect no or little fallout to appear. if anything does pop up please
  let me know so we can fix it.
 
  The pretty large changelog can be seen here --
  https://dev.openwrt.org/changeset/43108
 
  @Mingyu: thumbs up ! :)
 

 rt2880(gigabit) from 5x to 12x Mbps. - that's strange, I get 45Mbps
 with Asus RT-N15 and iperf without this improvement.
 mt7620 still 94Mbps. - what does it mean still? I would say it's
 pretty much maximum with fast ethernet ports. Or you mean stable?

 Regards,
 Roman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel