Re: [linux-sunxi] Banana Pi, Kernel 5.9, packet loss and bad network connectivity
Dne petek, 16. oktober 2020 ob 20:44:38 CEST je Marc Haber napisal(a): > Hi Jernej, > > On Thu, Oct 15, 2020 at 09:23:37PM +0200, Jernej Škrabec wrote: > > Dne četrtek, 15. oktober 2020 ob 21:11:39 CEST je Marc Haber napisal(a): > > > when I boot my Banana Pi (with Debian buster installed) with kernel 5.9, > > > the network interface doesn't work too well. Packet loss of more than > > > 50 %, machine nearly unuseable. Going back to 5.8.13 fixes the issue, > > > going forward to 5.9 again makes the issue reappear. > > > > > > Does anybody have a good guess what to try first before going the > > > "implant 5.8.13 stmmac driver to 5.9, maybe bisect" route? > > > > Try to revert https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ > > linux.git/commit/?h=v5.9=bbc4d71d63549bcd003a430de18a72a742d8c91e > > > > This commit was found to cause issue on Beelink GS1 (Allwinner H6) which > > has RTL8211e PHY. Since Banana Pi have same PHY, it might cause issue > > there too. > Reverting this commit does actually help here. Will there be a fix in > Greg's kernel releases? I have no clue. I don't have any problematic board, I just spotted commit when rebasing my kernel and suggested as a possible reason. I suggest that you contact all people involved in that commit (including relevant mailing lists) and explain the issue. Given that this commit is the fix, it's possible that it just uncovered another issue. Best regards, Jernej > > Thank you for helping! > > Greetings > Marc -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/1610036.Vb0S2D7GS0%40jernej-laptop.
Re: [linux-sunxi] Banana Pi, Kernel 5.9, packet loss and bad network connectivity
Hi Jernej, On Thu, Oct 15, 2020 at 09:23:37PM +0200, Jernej Škrabec wrote: > Dne četrtek, 15. oktober 2020 ob 21:11:39 CEST je Marc Haber napisal(a): > > when I boot my Banana Pi (with Debian buster installed) with kernel 5.9, > > the network interface doesn't work too well. Packet loss of more than > > 50 %, machine nearly unuseable. Going back to 5.8.13 fixes the issue, > > going forward to 5.9 again makes the issue reappear. > > > > Does anybody have a good guess what to try first before going the > > "implant 5.8.13 stmmac driver to 5.9, maybe bisect" route? > > Try to revert https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/ > linux.git/commit/?h=v5.9=bbc4d71d63549bcd003a430de18a72a742d8c91e > > This commit was found to cause issue on Beelink GS1 (Allwinner H6) which has > RTL8211e PHY. Since Banana Pi have same PHY, it might cause issue there too. Reverting this commit does actually help here. Will there be a fix in Greg's kernel releases? Thank you for helping! Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20201016184438.GR32306%40torres.zugschlus.de.
[linux-sunxi] Re: [PATCH] sunxi: make V3s DRAM initialization more proper
On 16/10/2020 10:33, Icenowy Zheng wrote:
Hi,
> Previously, because we have no source code about the DRAM initialization
> of V3s and missing some configurations (delays and MBUS QoS info), our
> V3s DRAM initialization sequence is hacked from the H3 one.
>
> As the SDK shipped with PineCube contains source code for V3s libdram,
> we can retrieve these information from it and tweak some other magic
> bits.
Nice! Thanks for taking care.
> Signed-off-by: Icenowy Zheng
I couldn't be asked to check the specific bits in the new V3s libdram,
nor do I have any hardware to test this, but I checked the integration
into the driver, and compile tested for the LicheePi and H3 boards.
The code size for H3 stayed the same, for the LicheePi it actually
decreased.
So from this perspective:
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
> arch/arm/mach-sunxi/dram_sunxi_dw.c | 91 +--
> 2 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
> b/arch/arm/include/asm/arch-sunxi/cpu.h
> index 4c399b0a15..8b57d24e2f 100644
> --- a/arch/arm/include/asm/arch-sunxi/cpu.h
> +++ b/arch/arm/include/asm/arch-sunxi/cpu.h
> @@ -16,6 +16,7 @@
>
> #define SOCID_A640x1689
> #define SOCID_H3 0x1680
> +#define SOCID_V3S0x1681
> #define SOCID_H5 0x1718
> #define SOCID_R400x1701
>
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index a462538521..d0600011ff 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -63,6 +63,8 @@ enum {
> MBUS_PORT_CSI = 5,
> MBUS_PORT_NAND = 6,
> MBUS_PORT_SS= 7,
> + MBUS_PORT_DE_V3S= 8,
> + MBUS_PORT_DE_CFD_V3S= 9,
> MBUS_PORT_TS= 8,
> MBUS_PORT_DI= 9,
> MBUS_PORT_DE= 10,
> @@ -134,6 +136,29 @@ static void mctl_set_master_priority_h3(void)
> MBUS_CONF(DE_CFD, true,HIGH, 0, 1024, 288, 64);
> }
>
> +static void mctl_set_master_priority_v3s(void)
> +{
> + struct sunxi_mctl_com_reg * const mctl_com =
> + (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
> +
> + /* enable bandwidth limit windows and set windows size 1us */
> + writel((1 << 16) | (400 << 0), _com->bwcr);
> +
> + /* set cpu high priority */
> + writel(0x0001, _com->mapr);
> +
> + MBUS_CONF( CPU, true, HIGHEST, 0, 160, 100, 80);
> + MBUS_CONF( GPU, true,HIGH, 0, 1792, 1536,0);
> + MBUS_CONF(UNUSED, true, HIGHEST, 0, 256, 128, 80);
> + MBUS_CONF( DMA, true,HIGH, 0, 256, 100,0);
> + MBUS_CONF(VE, true,HIGH, 0, 2048, 1600,0);
> + MBUS_CONF( CSI, true, HIGHEST, 0, 384, 256,0);
> + MBUS_CONF( NAND, true,HIGH, 0, 100, 50,0);
> + MBUS_CONF(SS, true,HIGH, 0, 384, 256,0);
> + MBUS_CONF(DE_V3S, false,HIGH, 0, 8192, 4096,0);
> + MBUS_CONF(DE_CFD_V3S, true,HIGH, 0, 640, 256,0);
> +}
> +
> static void mctl_set_master_priority_a64(void)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> @@ -231,6 +256,9 @@ static void mctl_set_master_priority(uint16_t socid)
> case SOCID_H3:
> mctl_set_master_priority_h3();
> return;
> + case SOCID_V3S:
> + mctl_set_master_priority_v3s();
> + return;
> case SOCID_A64:
> mctl_set_master_priority_a64();
> return;
> @@ -334,6 +362,28 @@ static void mctl_h3_zq_calibration_quirk(struct
> dram_para *para)
> }
> }
>
> +static void mctl_v3s_zq_calibration_quirk(struct dram_para *para)
> +{
> + struct sunxi_mctl_ctl_reg * const mctl_ctl =
> + (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> +
> + u32 reg_val;
> +
> + clrsetbits_le32(_ctl->zqcr, 0xff,
> + CONFIG_DRAM_ZQ & 0xff);
> + mctl_phy_init(PIR_ZCAL);
> +
> + reg_val = readl(_ctl->zqdr[0]);
> + reg_val &= (0x1f << 16) | (0x1f << 0);
> + reg_val |= reg_val << 8;
> + writel(reg_val, _ctl->zqdr[0]);
> +
> + reg_val = readl(_ctl->zqdr[1]);
> + reg_val &= (0x1f << 16) | (0x1f << 0);
> + reg_val |= reg_val << 8;
> + writel(reg_val, _ctl->zqdr[1]);
> +}
> +
> static void mctl_set_cr(uint16_t socid, struct dram_para *para)
> {
> struct sunxi_mctl_com_reg * const mctl_com =
> @@ -391,7 +441,7 @@ static void mctl_sys_init(uint16_t socid, struct
> dram_para *para)
> CCM_DRAMCLK_CFG_DIV(1) |
> CCM_DRAMCLK_CFG_SRC_PLL11 |
> CCM_DRAMCLK_CFG_UPD);
> - } else if (socid == SOCID_H3 || socid == SOCID_H5) {
> + } else if (socid == SOCID_H3 || socid == SOCID_H5 || socid ==
>
[linux-sunxi] [PATCH] sunxi: make V3s DRAM initialization more proper
Previously, because we have no source code about the DRAM initialization
of V3s and missing some configurations (delays and MBUS QoS info), our
V3s DRAM initialization sequence is hacked from the H3 one.
As the SDK shipped with PineCube contains source code for V3s libdram,
we can retrieve these information from it and tweak some other magic
bits.
Signed-off-by: Icenowy Zheng
---
arch/arm/include/asm/arch-sunxi/cpu.h | 1 +
arch/arm/mach-sunxi/dram_sunxi_dw.c | 91 +--
2 files changed, 87 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
b/arch/arm/include/asm/arch-sunxi/cpu.h
index 4c399b0a15..8b57d24e2f 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -16,6 +16,7 @@
#define SOCID_A64 0x1689
#define SOCID_H3 0x1680
+#define SOCID_V3S 0x1681
#define SOCID_H5 0x1718
#define SOCID_R40 0x1701
diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c
b/arch/arm/mach-sunxi/dram_sunxi_dw.c
index a462538521..d0600011ff 100644
--- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
+++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
@@ -63,6 +63,8 @@ enum {
MBUS_PORT_CSI = 5,
MBUS_PORT_NAND = 6,
MBUS_PORT_SS= 7,
+ MBUS_PORT_DE_V3S= 8,
+ MBUS_PORT_DE_CFD_V3S= 9,
MBUS_PORT_TS= 8,
MBUS_PORT_DI= 9,
MBUS_PORT_DE= 10,
@@ -134,6 +136,29 @@ static void mctl_set_master_priority_h3(void)
MBUS_CONF(DE_CFD, true,HIGH, 0, 1024, 288, 64);
}
+static void mctl_set_master_priority_v3s(void)
+{
+ struct sunxi_mctl_com_reg * const mctl_com =
+ (struct sunxi_mctl_com_reg *)SUNXI_DRAM_COM_BASE;
+
+ /* enable bandwidth limit windows and set windows size 1us */
+ writel((1 << 16) | (400 << 0), _com->bwcr);
+
+ /* set cpu high priority */
+ writel(0x0001, _com->mapr);
+
+ MBUS_CONF( CPU, true, HIGHEST, 0, 160, 100, 80);
+ MBUS_CONF( GPU, true,HIGH, 0, 1792, 1536,0);
+ MBUS_CONF(UNUSED, true, HIGHEST, 0, 256, 128, 80);
+ MBUS_CONF( DMA, true,HIGH, 0, 256, 100,0);
+ MBUS_CONF(VE, true,HIGH, 0, 2048, 1600,0);
+ MBUS_CONF( CSI, true, HIGHEST, 0, 384, 256,0);
+ MBUS_CONF( NAND, true,HIGH, 0, 100, 50,0);
+ MBUS_CONF(SS, true,HIGH, 0, 384, 256,0);
+ MBUS_CONF(DE_V3S, false,HIGH, 0, 8192, 4096,0);
+ MBUS_CONF(DE_CFD_V3S, true,HIGH, 0, 640, 256,0);
+}
+
static void mctl_set_master_priority_a64(void)
{
struct sunxi_mctl_com_reg * const mctl_com =
@@ -231,6 +256,9 @@ static void mctl_set_master_priority(uint16_t socid)
case SOCID_H3:
mctl_set_master_priority_h3();
return;
+ case SOCID_V3S:
+ mctl_set_master_priority_v3s();
+ return;
case SOCID_A64:
mctl_set_master_priority_a64();
return;
@@ -334,6 +362,28 @@ static void mctl_h3_zq_calibration_quirk(struct dram_para
*para)
}
}
+static void mctl_v3s_zq_calibration_quirk(struct dram_para *para)
+{
+ struct sunxi_mctl_ctl_reg * const mctl_ctl =
+ (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
+
+ u32 reg_val;
+
+ clrsetbits_le32(_ctl->zqcr, 0xff,
+ CONFIG_DRAM_ZQ & 0xff);
+ mctl_phy_init(PIR_ZCAL);
+
+ reg_val = readl(_ctl->zqdr[0]);
+ reg_val &= (0x1f << 16) | (0x1f << 0);
+ reg_val |= reg_val << 8;
+ writel(reg_val, _ctl->zqdr[0]);
+
+ reg_val = readl(_ctl->zqdr[1]);
+ reg_val &= (0x1f << 16) | (0x1f << 0);
+ reg_val |= reg_val << 8;
+ writel(reg_val, _ctl->zqdr[1]);
+}
+
static void mctl_set_cr(uint16_t socid, struct dram_para *para)
{
struct sunxi_mctl_com_reg * const mctl_com =
@@ -391,7 +441,7 @@ static void mctl_sys_init(uint16_t socid, struct dram_para
*para)
CCM_DRAMCLK_CFG_DIV(1) |
CCM_DRAMCLK_CFG_SRC_PLL11 |
CCM_DRAMCLK_CFG_UPD);
- } else if (socid == SOCID_H3 || socid == SOCID_H5) {
+ } else if (socid == SOCID_H3 || socid == SOCID_H5 || socid ==
SOCID_V3S) {
clock_set_pll5(CONFIG_DRAM_CLK * 2 * 100, false);
clrsetbits_le32(>dram_clk_cfg,
CCM_DRAMCLK_CFG_DIV_MASK |
@@ -474,6 +524,13 @@ static int mctl_channel_init(uint16_t socid, struct
dram_para *para)
/* dphy & aphy phase select 270 degree */
clrsetbits_le32(_ctl->pgcr[2], (0x3 << 10) | (0x3 << 8),
(0x1 << 10) | (0x2 << 8));
+ } else if (socid == SOCID_V3S) {
+ /* dx ddr_clk & hdr_clk
