[linux-sunxi] Re: [PATCH v2 1/2] musb: sunxi: Add set_mode platform function

2016-05-20 Thread Bin Liu 
Hi,

On Mon, May 16, 2016 at 03:11:34PM -0500, Bin Liu wrote:
> On Sat, May 14, 2016 at 02:45:04PM +0200, Hans de Goede wrote:
> > Move the mode handling to the platform_set_mode callback.
> > 
> > Signed-off-by: Hans de Goede 
> 
> Signed-off-by: Bin Liu 

I revised the subject prefix to "usb: musb: sunxi: ..." for both
patches.

Regards,
-Bin.

> 
> Regards,
> -Bin.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 0/7] spl: nand: sunxi: implement auto-detection

2016-05-20 Thread Boris Brezillon 
Hello,

This patch series aims at adding support for NAND auto-detection to
the sunxi SPL NAND driver.

As explained in patch 7, this auto-detection is nothing more than a
dumb "trial and error" logic, but it allows one to use the same
SPL binary for all kind of sunxi boards booting from NAND.
Of course, this approach might increase a bit the boot-time, but this
is something we could address by adding a "default NAND config",
that would be tested before launching the auto-detection procedure.

Now let's detail a bit what's inside this patch-set.
Patch 1 is a cleanup removing support for BootROM configs, which in
my opinion are not only inefficient but also not reliable (at least
the current implementation does not guarantee that you'll be using
the correct configuration when reading the NAND).

Piotr, Hans, any comment?
Is this a real problem if we get rid of syndrome/BootROM configs?
I mean, are you really using this mode? If that's not the case, I'd
prefer dropping support for this feature. ITOH, if you really
need this mode, then I'd recommend adding Kconfig options to specify
the exact config to be used rather than randomly testing configs
(see my explanation in patch 1).

Patch 2 is renaming the SYS_NAND_U_BOOT_OFFS Kconfig option to make it
usable on all platforms (not only sunxi) and avoid conflicts when
one board is defining CONFIG_SYS_NAND_U_BOOT_OFFS in its
include/configs/.h header.

Patch 3 is adding generic support for redundant u-boot images, which
is particularly useful on modern NANDs where corruptions is likely to
happen.
Patch 4 is just getting rid of the open-coded version of redundant
u-boot image support in the sunxi NAND driver.

Patch 5 is a simple improvement of the NAND controller status polling
loop, which is really important to make the "trial and error"
approach efficient (we try to limit the impact on boot-time here).
Patch 6 and 7 are implementing the auto-detection logic.


Best Regards,

Boris

Boris Brezillon (7):
  spl: nand: sunxi: remove support for so-called 'syndrome' mode
  spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option
  spl: nand: support redundant u-boot image
  spl: nand: sunxi: stop guessing the redundant u-boot offset
  spl: nand: sunxi: rework status polling loop
  spl: nand: sunxi: split 'load page' and 'read page' logic
  spl: nand: sunxi: add support for NAND config auto-detection

 common/spl/spl_nand.c |  12 +
 drivers/mtd/nand/Kconfig  |  15 +-
 drivers/mtd/nand/sunxi_nand_spl.c | 480 --
 3 files changed, 332 insertions(+), 175 deletions(-)

-- 
2.7.4

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 1/7] spl: nand: sunxi: remove support for so-called 'syndrome' mode

2016-05-20 Thread Boris Brezillon 
The sunxi SPL NAND controller driver supports use 'BootROM'-like configs,
that is, configs where the ECC bytes and real data are interleaved in the
page instead of putting ECC bytes in the OOB area.

Doing that has several drawbacks:
- since you're interleaving data and ECC bytes you can't use the whole page
  otherwise you might override the bad block marker with non-FF bytes.
- to solve the bad block marker problem, the ROM code supports partially
  using the page, but this introduces a huge penalty both in term of read
  speed and NAND memory usage. While this is fine for rather small
  binaries(like the SPL one which is at maximum 24KB large), it becomes
  non-negligible for the bootloader image (several hundred of KB).
- auto-detection of the page size is not reliable (this is in my opinion
  the biggest problem). If you get the page size wrong, you'll end up
  reading data at a different offset than what was specified by the caller
  and the reading may succeed (if valid data were written at this address).

For all those reasons I think it's wiser to completely remove support for
'syndrome' configs. If we ever need to support it again, then I'd recommend
specifying all the config parameters through Kconfig options.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 56 ++-
 1 file changed, 14 insertions(+), 42 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b0e07aa..1739da2 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,9 +119,6 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-/* random seed used for syndrome calls */
-const uint16_t random_seed_syndrome = 0x4a80;
-
 #define MAX_RETRIES 10
 
 static int check_value_inner(int offset, int expected_bits,
@@ -183,7 +180,7 @@ void nand_init(void)
 }
 
 static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst, int syndrome)
+   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
 {
uint32_t val;
int i, ecc_off = 0;
@@ -209,17 +206,11 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
page = real_addr / page_size;
column = real_addr % page_size;
 
-   if (syndrome)
-   column += (column / ecc_page_size) * ecc_off;
-
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   if (syndrome)
-   rand_seed = random_seed_syndrome;
-   else
-   rand_seed = random_seed[page % 128];
+   rand_seed = random_seed[page % 128];
 
writel((rand_seed << 16) | NFC_ECC_RANDOM_EN | NFC_ECC_EN
| NFC_ECC_PIPELINE | (ecc_mode << 12),
@@ -228,9 +219,8 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
val = readl(SUNXI_NFC_BASE + NFC_CTL);
writel(val | NFC_CTL_RAM_METHOD, SUNXI_NFC_BASE + NFC_CTL);
 
-   if (!syndrome)
-   writel(page_size + (column / ecc_page_size) * ecc_off,
-  SUNXI_NFC_BASE + NFC_SPARE_AREA);
+   writel(page_size + (column / ecc_page_size) * ecc_off,
+  SUNXI_NFC_BASE + NFC_SPARE_AREA);
 
flush_dcache_range(dst, ALIGN(dst + ecc_page_size, ARCH_DMA_MINALIGN));
 
@@ -266,7 +256,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_DATA_TRANS |
NFC_PAGE_CMD | NFC_WAIT_FLAG |
((addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) |
-   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD | (syndrome ? NFC_SEQ : 0),
+   NFC_SEND_ADR | NFC_DATA_SWAP_METHOD,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
@@ -292,7 +282,7 @@ static int nand_read_page(int page_size, int ecc_strength, 
int ecc_page_size,
 }
 
 static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest, int syndrome)
+   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
 {
void *end = dest + size;
 
@@ -301,16 +291,14 @@ static int nand_read_ecc(int page_size, int ecc_strength, 
int ecc_page_size,
 
for ( ;dest < end; dest += ecc_page_size, offs += ecc_page_size) {
if (nand_read_page(page_size, ecc_strength, ecc_page_size,
-  addr_cycles, offs, (dma_addr_t)dest,
-  syndrome))
+  addr_cycles, offs, (dma_addr_t)dest))
return -1;
}
 
return 0;
 }
 
-static int nand_read_buffer(uint32_t offs, unsigned int size, void *dest,
-

[linux-sunxi] [PATCH 5/7] spl: nand: sunxi: rework status polling loop

2016-05-20 Thread Boris Brezillon 
check_value_xxx() helpers are using a 1ms delay between each test, which
can be quite long for some operations (like a page read on an SLC NAND).
Since we don't have anything to do but to poll this register, reduce the
delay between each test to 1us.

While we're at it, rename the max_number_of_retries parameters and the
MAX_RETRIES macro into timeout_us and DEFAULT_TIMEOUT_US to reflect that
we're actually waiting a given amount of time and not only a number of
retries.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 13e6eab..55b3c8a 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -119,35 +119,31 @@ const uint16_t random_seed[128] = {
0x7c57, 0x0fbe, 0x46ce, 0x4939, 0x6b17, 0x37bb, 0x3e91, 0x76db,
 };
 
-#define MAX_RETRIES 10
+#define DEFAULT_TIMEOUT_US 10
 
 static int check_value_inner(int offset, int expected_bits,
-   int max_number_of_retries, int negation)
+int timeout_us, int negation)
 {
-   int retries = 0;
do {
int val = readl(offset) & expected_bits;
if (negation ? !val : val)
return 1;
-   mdelay(1);
-   retries++;
-   } while (retries < max_number_of_retries);
+   udelay(1);
+   } while (--timeout_us);
 
return 0;
 }
 
 static inline int check_value(int offset, int expected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, expected_bits,
-   max_number_of_retries, 0);
+   return check_value_inner(offset, expected_bits, timeout_us, 0);
 }
 
 static inline int check_value_negated(int offset, int unexpected_bits,
-   int max_number_of_retries)
+ int timeout_us)
 {
-   return check_value_inner(offset, unexpected_bits,
-   max_number_of_retries, 1);
+   return check_value_inner(offset, unexpected_bits, timeout_us, 1);
 }
 
 void nand_init(void)
@@ -162,7 +158,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CTL);
 
if (!check_value_negated(SUNXI_NFC_BASE + NFC_CTL,
-NFC_CTL_RESET, MAX_RETRIES)) {
+NFC_CTL_RESET, DEFAULT_TIMEOUT_US)) {
printf("Couldn't initialize nand\n");
}
 
@@ -172,7 +168,7 @@ void nand_init(void)
   SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error timeout waiting for nand reset\n");
return;
}
@@ -260,14 +256,15 @@ static int nand_read_page(int page_size, int 
ecc_strength, int ecc_page_size,
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_DMA_INT_FLAG,
-MAX_RETRIES)) {
+DEFAULT_TIMEOUT_US)) {
printf("Error while initializing dma interrupt\n");
return -1;
}
writel(NFC_ST_DMA_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 
if (!check_value_negated(SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0,
-SUNXI_DMA_DDMA_CFG_REG_LOADING, MAX_RETRIES)) {
+SUNXI_DMA_DDMA_CFG_REG_LOADING,
+DEFAULT_TIMEOUT_US)) {
printf("Error while waiting for dma transfer to finish\n");
return -1;
}
-- 
2.7.4

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 7/7] spl: nand: sunxi: add support for NAND config auto-detection

2016-05-20 Thread Boris Brezillon 
NAND chips are supposed to expose their capabilities through advanced
mechanisms like READID, ONFI or JEDEC parameter tables. While those
methods are appropriate for the bootloader itself, it's way to
complicated and takes too much space to fit in the SPL.

Replace those mechanisms by a dumb 'trial and error' mechanism.

With this new approach we can get rid of the fixed config list that was
used in the sunxi NAND SPL driver.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 262 +-
 1 file changed, 204 insertions(+), 58 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index b43f2af..cc2e69b 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -103,6 +103,7 @@ struct nfc_config {
int addr_cycles;
int nseeds;
bool randomize;
+   bool valid;
 };
 
 /* minimal "boot0" style NAND support for Allwinner A20 */
@@ -219,6 +220,26 @@ static int nand_load_page(const struct nfc_config *conf, 
u32 offs)
return 0;
 }
 
+static int nand_reset_column(void)
+{
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_RNDOUTSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(0, SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD |
+  (1 << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR | NFC_CMD_RNDOUT,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static int nand_read_page(const struct nfc_config *conf, u32 offs,
  void *dest, int len)
 {
@@ -303,88 +324,213 @@ static int nand_read_page(const struct nfc_config *conf, 
u32 offs,
return (val & 0x1) ? 1 : 0;
 }
 
-static int nand_read_ecc(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t offs, uint32_t size, void *dest)
+static int nand_max_ecc_strength(struct nfc_config *conf)
 {
-   void *end = dest + size;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
-   struct nfc_config conf = {
-   .page_size = page_size,
-   .ecc_size = ecc_page_size,
-   .addr_cycles = addr_cycles,
-   .nseeds = ARRAY_SIZE(random_seed),
-   .randomize = true,
-   };
+   static const int ecc_bytes[] = { 32, 46, 54, 60, 74, 88, 102, 110, 116 
};
+   int max_oobsize, max_ecc_bytes;
+   int nsectors = conf->page_size / conf->ecc_size;
int i;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   conf.ecc_strength = i;
+   /*
+* ECC strength is limited by the size of the OOB area which is
+* correlated with the page size.
+*/
+   switch (conf->page_size) {
+   case 2048:
+   max_oobsize = 64;
+   break;
+   case 4096:
+   max_oobsize = 256;
+   break;
+   case 8196:
+   max_oobsize = 620;
+   break;
+   case 16384:
+   max_oobsize = 1664;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   max_ecc_bytes = max_oobsize / nsectors;
+
+   for (i = 0; i < ARRAY_SIZE(ecc_bytes); i++) {
+   if (ecc_bytes[i] > max_ecc_bytes)
break;
-   }
}
 
+   if (!i)
+   return -EINVAL;
 
-   nand_apply_config();
+   return i - 1;
+}
 
-   for ( ;dest < end; dest += ecc_page_size, offs += page_size) {
-   if (nand_load_page(, offs))
-   return -1;
+static int nand_detect_ecc_config(struct nfc_config *conf, u32 offs,
+ void *dest)
+{
+   /* NAND with pages > 4k will likely require 1k sector size. */
+   int min_ecc_size = conf->page_size > 4096 ? 1024 : 512;
+   int page = offs / conf->page_size;
+   int ret;
 
-   if (nand_read_page(, offs, dest, page_size))
-   return -1;
+   /*
+* In most cases, 1k sectors are preferred over 512b ones, start
+* testing this config first.
+*/
+   for (conf->ecc_size = 1024; conf->ecc_size >= min_ecc_size;
+conf->ecc_size >>= 1) {
+   int max_ecc_strength = nand_max_ecc_strength(conf);
+
+   nand_apply_config(conf);
+
+   /*
+* We are starting from the maximum ECC strength because
+* most of the time NAND vendors

[linux-sunxi] [PATCH 4/7] spl: nand: sunxi: stop guessing the redundant u-boot offset

2016-05-20 Thread Boris Brezillon 
Use CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND value instead of trying to guess
where the redundant u-boot image is based on simple (and most of the time
erroneous) heuristics.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 85cb127..13e6eab 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -344,26 +344,6 @@ static int nand_read_buffer(uint32_t offs, unsigned int 
size, void *dest)
 
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 {
-   /*
-* u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
-* for backup u-boot 1 erase block further.
-*/
-   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
-   const uint32_t boot_offsets[] = {
-   CONFIG_SPL_NAND_U_BOOT_OFFS,
-   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
-   };
-   int i;
-
-   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
-   for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
-   if (nand_read_buffer(boot_offsets[i], size,
-dest) == 0)
-   return 0;
-   }
-   return -1;
-   }
-
return nand_read_buffer(offs, size, dest);
 }
 
-- 
2.7.4

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 3/7] spl: nand: support redundant u-boot image

2016-05-20 Thread Boris Brezillon 
On modern NAND it's more than recommended to have a backup copy of the
u-boot binary to recover from corruption: bitflips are quite common on
MLC NANDs, and the read-disturbance will corrupt your u-boot partitition
more quickly than what you would see on an SLC NAND.

Add an extra Kconfig option to specify the offset of the redundant u-boot
image.

Signed-off-by: Boris Brezillon 
---
 common/spl/spl_nand.c| 8 
 drivers/mtd/nand/Kconfig | 6 ++
 2 files changed, 14 insertions(+)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index 612bd4a..0bf0848 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -12,6 +12,9 @@
 
 #ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
 #define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SPL_NAND_U_BOOT_OFFS_REDUND
+#else
+#define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND CONFIG_SYS_NAND_U_BOOT_OFFS
 #endif
 
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
@@ -111,6 +114,11 @@ int spl_nand_load_image(void)
 #endif
/* Load u-boot */
err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS, header);
+#if CONFIG_SYS_NAND_U_BOOT_OFFS != CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND
+   if (err)
+   err = spl_nand_load_element(CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND,
+   header);
+#endif
nand_deselect();
return err;
 }
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 4b0f92c..2f1d1f7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -110,6 +110,12 @@ config SPL_NAND_U_BOOT_OFFS
Set the offset from the start of the nand where u-boot should be
loaded from.
 
+config SPL_NAND_U_BOOT_OFFS_REDUND
+   hex "Location in NAND to read U-Boot from"
+   default SPL_NAND_U_BOOT_OFFS
+   help
+   Set the offset from the start of the nand where u-boot should be
+   loaded from.
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
-- 
2.7.4

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 6/7] spl: nand: sunxi: split 'load page' and 'read page' logic

2016-05-20 Thread Boris Brezillon 
Split the 'load page' and 'read page' logic in 2 different functions so
we can later load the page and test different ECC configs without the
penalty of reloading the same page in the NAND cache.

We also move common setup to a dedicated function (nand_apply_config()) to
avoid rewriting the same values in NFC registers each time we read a page.

These new functions are passed a pointer to an nfc_config struct to limit
the number of parameters.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 185 +++---
 1 file changed, 114 insertions(+), 71 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 55b3c8a..b43f2af 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -66,6 +66,8 @@
 #define NFC_ROW_AUTO_INC   (1 << 27)
 #define NFC_SEND_CMD3  (1 << 28)
 #define NFC_SEND_CMD4  (1 << 29)
+#define NFC_RAW_CMD(0 << 30)
+#define NFC_PAGE_CMD   (2 << 30)
 
 #define NFC_ST_CMD_INT_FLAG(1 << 1)
 #define NFC_ST_DMA_INT_FLAG(1 << 2)
@@ -78,9 +80,6 @@
 #define NFC_CMD_RNDOUT 0x05
 #define NFC_CMD_READSTART  0x30
 
-
-#define NFC_PAGE_CMD   (2 << 30)
-
 #define SUNXI_DMA_CFG_REG0  0x300
 #define SUNXI_DMA_SRC_START_ADDR_REG0   0x304
 #define SUNXI_DMA_DEST_START_ADDRR_REG0 0x308
@@ -97,6 +96,15 @@
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC (0x0F << 0)
 #define SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE (0x7F << 8)
 
+struct nfc_config {
+   int page_size;
+   int ecc_strength;
+   int ecc_size;
+   int addr_cycles;
+   int nseeds;
+   bool randomize;
+};
+
 /* minimal "boot0" style NAND support for Allwinner A20 */
 
 /* random seed used by linux */
@@ -175,50 +183,70 @@ void nand_init(void)
writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
 }
 
-static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
-   int addr_cycles, uint32_t real_addr, dma_addr_t dst)
+static void nand_apply_config(const struct nfc_config *conf)
 {
-   uint32_t val;
-   int i, ecc_off = 0;
-   uint16_t ecc_mode = 0;
-   uint16_t rand_seed;
-   uint32_t page;
-   uint16_t column;
-   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
+   u32 val;
 
-   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (ecc_strength == strengths[i]) {
-   ecc_mode = i;
-   break;
-   }
+   val = readl(SUNXI_NFC_BASE + NFC_CTL);
+   val &= ~NFC_CTL_PAGE_SIZE_MASK;
+   writel(val | NFC_CTL_RAM_METHOD | NFC_CTL_PAGE_SIZE(conf->page_size),
+  SUNXI_NFC_BASE + NFC_CTL);
+   writel(conf->ecc_size, SUNXI_NFC_BASE + NFC_CNT);
+   writel(conf->page_size, SUNXI_NFC_BASE + NFC_SPARE_AREA);
+}
+
+static int nand_load_page(const struct nfc_config *conf, u32 offs)
+{
+   int page = offs / conf->page_size;
+
+   writel((NFC_CMD_RNDOUTSTART << NFC_RANDOM_READ_CMD1_OFFSET) |
+  (NFC_CMD_RNDOUT << NFC_RANDOM_READ_CMD0_OFFSET) |
+  (NFC_CMD_READSTART << NFC_READ_CMD_OFFSET),
+  SUNXI_NFC_BASE + NFC_RCMD_SET);
+   writel(((page & 0x) << 16), SUNXI_NFC_BASE + NFC_ADDR_LOW);
+   writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
+   writel(NFC_ST_CMD_INT_FLAG, SUNXI_NFC_BASE + NFC_ST);
+   writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_RAW_CMD | NFC_WAIT_FLAG |
+  ((conf->addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) | NFC_SEND_ADR,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_ST_CMD_INT_FLAG,
+DEFAULT_TIMEOUT_US)) {
+   printf("Error while initializing dma interrupt\n");
+   return -EIO;
}
 
-   /* HW ECC always request ECC bytes for 1024 bytes blocks */
-   ecc_off = DIV_ROUND_UP(ecc_strength * fls(8 * 1024), 8);
-   /* HW ECC always work with even numbers of ECC bytes */
-   ecc_off += (ecc_off & 1);
-   ecc_off += 4; /* prepad */
+   return 0;
+}
+
+static int nand_read_page(const struct nfc_config *conf, u32 offs,
+ void *dest, int len)
+{
+   dma_addr_t dst = (dma_addr_t)dest;
+   int nsectors = len / conf->ecc_size;
+   u16 rand_seed;
+   u32 val;
+   int page;
+
+   page = offs / conf->page_size;
 
-   page = real_addr / page_size;
-   column = real_addr % page_size;
+   if (offs % conf->page_size || len % conf->ecc_size ||
+   len > conf->page_size || len < 0)
+   return -EINVAL;
 
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
 
/* Choose correct seed */
-   rand_seed = random_seed[page % 128];
+   rand_seed = random_seed[page % conf->nseeds];

[linux-sunxi] [PATCH 2/7] spl: nand: rename the SYS_NAND_U_BOOT_OFFS Kconfig option

2016-05-20 Thread Boris Brezillon 
The SYS_NAND_U_BOOT_OFFS is quite generic, but the Kconfig entry is forced
to explicitly depend on platforms that are not already defining it in their
include/configs/.h header.

Rename this Kconfig option into SPL_NAND_U_BOOT_OFFS, remove the dependency
on NAND_SUNXI and make it dependent on SPL selection.

common/spl/spl_nand.c now sets CONFIG_SYS_NAND_U_BOOT_OFFS to
CONFIG_SPL_NAND_U_BOOT_OFFS only when it's undefined. This way we stay
compatible with the existing behavior.

Signed-off-by: Boris Brezillon 
---
 common/spl/spl_nand.c | 4 
 drivers/mtd/nand/Kconfig  | 9 +
 drivers/mtd/nand/sunxi_nand_spl.c | 8 
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c
index bbd9546..612bd4a 100644
--- a/common/spl/spl_nand.c
+++ b/common/spl/spl_nand.c
@@ -10,6 +10,10 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_NAND_U_BOOT_OFFS
+#define CONFIG_SYS_NAND_U_BOOT_OFFS CONFIG_SPL_NAND_U_BOOT_OFFS
+#endif
+
 #if defined(CONFIG_SPL_NAND_RAW_ONLY)
 int spl_nand_load_image(void)
 {
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 2fc73ef..4b0f92c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -99,16 +99,17 @@ config SYS_NAND_BUSWIDTH_16BIT
not available while configuring controller. So a static 
CONFIG_NAND_xx
is needed to know the device's bus-width in advance.
 
-# Enhance depends when converting drivers to Kconfig which use this config
-config SYS_NAND_U_BOOT_OFFS
+if SPL
+
+# This option should be used in replacement of CONFIG_SYS_NAND_U_BOOT_OFFS.
+# CONFIG_SYS_NAND_U_BOOT_OFFS is still preferred if defined.
+config SPL_NAND_U_BOOT_OFFS
hex "Location in NAND to read U-Boot from"
default 0x8000 if NAND_SUNXI
-   depends on NAND_SUNXI
help
Set the offset from the start of the nand where u-boot should be
loaded from.
 
-if SPL
 
 config SPL_NAND_DENALI
bool "Support Denali NAND controller for SPL"
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 1739da2..85cb127 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -348,14 +348,14 @@ int nand_spl_load_image(uint32_t offs, unsigned int size, 
void *dest)
 * u-boot partition sits after 2 eraseblocks (spl, spl-backup), look
 * for backup u-boot 1 erase block further.
 */
-   const uint32_t eraseblock_size = CONFIG_SYS_NAND_U_BOOT_OFFS / 2;
+   const uint32_t eraseblock_size = CONFIG_SPL_NAND_U_BOOT_OFFS / 2;
const uint32_t boot_offsets[] = {
-   CONFIG_SYS_NAND_U_BOOT_OFFS,
-   CONFIG_SYS_NAND_U_BOOT_OFFS + eraseblock_size,
+   CONFIG_SPL_NAND_U_BOOT_OFFS,
+   CONFIG_SPL_NAND_U_BOOT_OFFS + eraseblock_size,
};
int i;
 
-   if (offs == CONFIG_SYS_NAND_U_BOOT_OFFS) {
+   if (offs == CONFIG_SPL_NAND_U_BOOT_OFFS) {
for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
if (nand_read_buffer(boot_offsets[i], size,
 dest) == 0)
-- 
2.7.4

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)

2016-05-20 Thread Andre Heider 
Hi,

On Fri, May 20, 2016 at 12:36 PM, Marc Zyngier  wrote:
> On 20/05/16 11:30, Andre Heider wrote:
>> Hi,
>>
>> On Fri, May 20, 2016 at 10:14 AM, Giuseppe CAVALLARO
>>  wrote:
>>> On 5/20/2016 9:56 AM, Marc Zyngier wrote:

 On 20/05/16 06:44, Andre Heider wrote:
>
> Giuseppe, Alexandre, et al.,
>
> On Thu, Mar 17, 2016 at 8:52 AM, Marc Zyngier 
> wrote:
>>
>> On Thu, 17 Mar 2016 00:56:40 +0100
>> Bert Lindner  wrote:
>>>
>>> On 2016-03-16 18:42, Marc Zyngier wrote:

 On 16/03/16 15:10, Bert Lindner wrote:
>
> On 2016-03-16 14:10, Andreas Färber wrote:
>>
>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>>>
>>> On 16/03/16 11:39, Marc Zyngier wrote:

 On 16/03/16 11:19, Bert Lindner wrote:
>
> ...
>
> For the board sun7i-a20-olinuxino-lime2, there seems to be a
> problem
> with the eth0 PHY in mainline kernel 4.5.0 that developed since
> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
>
> ...
>
> [9.767125] NET: Registered protocol family 10
> [   10.357405] libphy: PHY stmmac-0: not found
> [   10.362382] eth0: Could not attach to PHY
> [   10.366557] stmmac_open: Cannot attach to PHY (error: -19)
>
> ...
>>
>> v4 fixes for 4.5 are here:
>>
>> https://patchwork.ozlabs.org/patch/598195/ (revert)
>> https://patchwork.ozlabs.org/patch/598196/
>
> ...

 Good to know, thanks. Could you also give the potential fix a go (as
 mentioned by Andreas)? Just to make sure that whatever gets merged
 next
 will actually fix the issue.
>>>
>>>
>>> Yes sure, it took a while because I had to travel. Confirmed, the
>>> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>>>
>>> root@lime2-079f:~# cat /proc/version
>>> Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
>>> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC
>>> 2016
>>>
>>> dmesg:
>>> [8.245273] NET: Registered protocol family 10
>>> [9.297406]  RX IPC Checksum Offload disabled
>>> [9.297460]  No MAC Management Counters available
>>> [9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> [   16.285658] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
>>> 1Gbps/Full - flow control rx/tx
>>> [   16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>
>>> The board is connected to my laptop rather than to a switch, so that
>>> might be where the flow control message comes from (not sure). Anyway
>>> ethernet works.
>>
>>
>> Cool, many thanks for taking the time to test and report.
>>
>> Hopefully Giuseppe will get this merged quickly enough in mainline, and
>> it should then trickle into a 4.5-stable release (cc-ing stable on
>> these patches would probably be a good idea, BTW).
>
>
> stmmac is broken on at least Lime2, BananaPi and Cubieboard2 since
> v4.5 [0], including all five stable releases :(


 All the A20 platforms are dead, actually.

> The v4.5 patches quoted above are already +4 weeks old, could we
> please get them into stable?


 For that, the maintainer would have needed to CC stable, which he
 didn't. I'd expect someone who cares to send these patches to stable.
 It'd be better if the maintainer would do it himself though.
>>>
>>>
>>> sure, I can send the patches to stable (sorry if I missed to add
>>> stable ML on CC).
>>>
>>> Andre, I have not clear if the train of patches actually fix the
>>> issue or if you need my support to fix something else. In that case
>>> I need some input for debugging (e.g. kernel log).
>>
>> Bert already confirmed that those two patches fixes stmmac on his
>> Lime2, so I assume that it fixes the issue for all A20 platforms.
>>
>>> let me know, is it enough to re-send the patches only?
>>
>> Just a resend with cc:stable :)
>
> Not quite. Please read Documentation/stable_kernel_rules.txt, and the
> section that concerns networking patches (and then consult
> Documentation/networking/netdev-FAQ.txt which has all the details).

Right, it's just been a while since I sent a patch.
What I really meant was "do what's neccessary for -stable inclusion" :)

Regards,
Andre

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)

2016-05-20 Thread Marc Zyngier 
On 20/05/16 11:30, Andre Heider wrote:
> Hi,
> 
> On Fri, May 20, 2016 at 10:14 AM, Giuseppe CAVALLARO
>  wrote:
>> On 5/20/2016 9:56 AM, Marc Zyngier wrote:
>>>
>>> On 20/05/16 06:44, Andre Heider wrote:

 Giuseppe, Alexandre, et al.,

 On Thu, Mar 17, 2016 at 8:52 AM, Marc Zyngier 
 wrote:
>
> On Thu, 17 Mar 2016 00:56:40 +0100
> Bert Lindner  wrote:
>>
>> On 2016-03-16 18:42, Marc Zyngier wrote:
>>>
>>> On 16/03/16 15:10, Bert Lindner wrote:

 On 2016-03-16 14:10, Andreas Färber wrote:
>
> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>>
>> On 16/03/16 11:39, Marc Zyngier wrote:
>>>
>>> On 16/03/16 11:19, Bert Lindner wrote:

 ...

 For the board sun7i-a20-olinuxino-lime2, there seems to be a
 problem
 with the eth0 PHY in mainline kernel 4.5.0 that developed since
 4.5.0-rc7. Ethernet does not work, although eth0 is reported:

 ...

 [9.767125] NET: Registered protocol family 10
 [   10.357405] libphy: PHY stmmac-0: not found
 [   10.362382] eth0: Could not attach to PHY
 [   10.366557] stmmac_open: Cannot attach to PHY (error: -19)

 ...
>
> v4 fixes for 4.5 are here:
>
> https://patchwork.ozlabs.org/patch/598195/ (revert)
> https://patchwork.ozlabs.org/patch/598196/

 ...
>>>
>>> Good to know, thanks. Could you also give the potential fix a go (as
>>> mentioned by Andreas)? Just to make sure that whatever gets merged
>>> next
>>> will actually fix the issue.
>>
>>
>> Yes sure, it took a while because I had to travel. Confirmed, the
>> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>>
>> root@lime2-079f:~# cat /proc/version
>> Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
>> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC
>> 2016
>>
>> dmesg:
>> [8.245273] NET: Registered protocol family 10
>> [9.297406]  RX IPC Checksum Offload disabled
>> [9.297460]  No MAC Management Counters available
>> [9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [   16.285658] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
>> 1Gbps/Full - flow control rx/tx
>> [   16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> The board is connected to my laptop rather than to a switch, so that
>> might be where the flow control message comes from (not sure). Anyway
>> ethernet works.
>
>
> Cool, many thanks for taking the time to test and report.
>
> Hopefully Giuseppe will get this merged quickly enough in mainline, and
> it should then trickle into a 4.5-stable release (cc-ing stable on
> these patches would probably be a good idea, BTW).


 stmmac is broken on at least Lime2, BananaPi and Cubieboard2 since
 v4.5 [0], including all five stable releases :(
>>>
>>>
>>> All the A20 platforms are dead, actually.
>>>
 The v4.5 patches quoted above are already +4 weeks old, could we
 please get them into stable?
>>>
>>>
>>> For that, the maintainer would have needed to CC stable, which he
>>> didn't. I'd expect someone who cares to send these patches to stable.
>>> It'd be better if the maintainer would do it himself though.
>>
>>
>> sure, I can send the patches to stable (sorry if I missed to add
>> stable ML on CC).
>>
>> Andre, I have not clear if the train of patches actually fix the
>> issue or if you need my support to fix something else. In that case
>> I need some input for debugging (e.g. kernel log).
> 
> Bert already confirmed that those two patches fixes stmmac on his
> Lime2, so I assume that it fixes the issue for all A20 platforms.
> 
>> let me know, is it enough to re-send the patches only?
> 
> Just a resend with cc:stable :)

Not quite. Please read Documentation/stable_kernel_rules.txt, and the
section that concerns networking patches (and then consult
Documentation/networking/netdev-FAQ.txt which has all the details).

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)

2016-05-20 Thread Andre Heider 
Hi,

On Fri, May 20, 2016 at 10:14 AM, Giuseppe CAVALLARO
 wrote:
> On 5/20/2016 9:56 AM, Marc Zyngier wrote:
>>
>> On 20/05/16 06:44, Andre Heider wrote:
>>>
>>> Giuseppe, Alexandre, et al.,
>>>
>>> On Thu, Mar 17, 2016 at 8:52 AM, Marc Zyngier 
>>> wrote:

 On Thu, 17 Mar 2016 00:56:40 +0100
 Bert Lindner  wrote:
>
> On 2016-03-16 18:42, Marc Zyngier wrote:
>>
>> On 16/03/16 15:10, Bert Lindner wrote:
>>>
>>> On 2016-03-16 14:10, Andreas Färber wrote:

 Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>
> On 16/03/16 11:39, Marc Zyngier wrote:
>>
>> On 16/03/16 11:19, Bert Lindner wrote:
>>>
>>> ...
>>>
>>> For the board sun7i-a20-olinuxino-lime2, there seems to be a
>>> problem
>>> with the eth0 PHY in mainline kernel 4.5.0 that developed since
>>> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
>>>
>>> ...
>>>
>>> [9.767125] NET: Registered protocol family 10
>>> [   10.357405] libphy: PHY stmmac-0: not found
>>> [   10.362382] eth0: Could not attach to PHY
>>> [   10.366557] stmmac_open: Cannot attach to PHY (error: -19)
>>>
>>> ...

 v4 fixes for 4.5 are here:

 https://patchwork.ozlabs.org/patch/598195/ (revert)
 https://patchwork.ozlabs.org/patch/598196/
>>>
>>> ...
>>
>> Good to know, thanks. Could you also give the potential fix a go (as
>> mentioned by Andreas)? Just to make sure that whatever gets merged
>> next
>> will actually fix the issue.
>
>
> Yes sure, it took a while because I had to travel. Confirmed, the
> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>
> root@lime2-079f:~# cat /proc/version
> Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC
> 2016
>
> dmesg:
> [8.245273] NET: Registered protocol family 10
> [9.297406]  RX IPC Checksum Offload disabled
> [9.297460]  No MAC Management Counters available
> [9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   16.285658] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
> 1Gbps/Full - flow control rx/tx
> [   16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>
> The board is connected to my laptop rather than to a switch, so that
> might be where the flow control message comes from (not sure). Anyway
> ethernet works.


 Cool, many thanks for taking the time to test and report.

 Hopefully Giuseppe will get this merged quickly enough in mainline, and
 it should then trickle into a 4.5-stable release (cc-ing stable on
 these patches would probably be a good idea, BTW).
>>>
>>>
>>> stmmac is broken on at least Lime2, BananaPi and Cubieboard2 since
>>> v4.5 [0], including all five stable releases :(
>>
>>
>> All the A20 platforms are dead, actually.
>>
>>> The v4.5 patches quoted above are already +4 weeks old, could we
>>> please get them into stable?
>>
>>
>> For that, the maintainer would have needed to CC stable, which he
>> didn't. I'd expect someone who cares to send these patches to stable.
>> It'd be better if the maintainer would do it himself though.
>
>
> sure, I can send the patches to stable (sorry if I missed to add
> stable ML on CC).
>
> Andre, I have not clear if the train of patches actually fix the
> issue or if you need my support to fix something else. In that case
> I need some input for debugging (e.g. kernel log).

Bert already confirmed that those two patches fixes stmmac on his
Lime2, so I assume that it fixes the issue for all A20 platforms.

> let me know, is it enough to re-send the patches only?

Just a resend with cc:stable :)

Thanks!
Andre

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)

2016-05-20 Thread Andre Heider 
Giuseppe, Alexandre, et al.,

On Thu, Mar 17, 2016 at 8:52 AM, Marc Zyngier  wrote:
> On Thu, 17 Mar 2016 00:56:40 +0100
> Bert Lindner  wrote:
>> On 2016-03-16 18:42, Marc Zyngier wrote:
>> > On 16/03/16 15:10, Bert Lindner wrote:
>> >> On 2016-03-16 14:10, Andreas Färber wrote:
>> >>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>>  On 16/03/16 11:39, Marc Zyngier wrote:
>> > On 16/03/16 11:19, Bert Lindner wrote:
...
>> >> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
>> >> with the eth0 PHY in mainline kernel 4.5.0 that developed since
>> >> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
...
>> >> [9.767125] NET: Registered protocol family 10
>> >> [   10.357405] libphy: PHY stmmac-0: not found
>> >> [   10.362382] eth0: Could not attach to PHY
>> >> [   10.366557] stmmac_open: Cannot attach to PHY (error: -19)
...
>> >>> v4 fixes for 4.5 are here:
>> >>>
>> >>> https://patchwork.ozlabs.org/patch/598195/ (revert)
>> >>> https://patchwork.ozlabs.org/patch/598196/
...
>> > Good to know, thanks. Could you also give the potential fix a go (as
>> > mentioned by Andreas)? Just to make sure that whatever gets merged next
>> > will actually fix the issue.
>>
>> Yes sure, it took a while because I had to travel. Confirmed, the
>> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>>
>> root@lime2-079f:~# cat /proc/version
>> Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
>> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC 2016
>>
>> dmesg:
>> [8.245273] NET: Registered protocol family 10
>> [9.297406]  RX IPC Checksum Offload disabled
>> [9.297460]  No MAC Management Counters available
>> [9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [   16.285658] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
>> 1Gbps/Full - flow control rx/tx
>> [   16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> The board is connected to my laptop rather than to a switch, so that
>> might be where the flow control message comes from (not sure). Anyway
>> ethernet works.
>
> Cool, many thanks for taking the time to test and report.
>
> Hopefully Giuseppe will get this merged quickly enough in mainline, and
> it should then trickle into a 4.5-stable release (cc-ing stable on
> these patches would probably be a good idea, BTW).

stmmac is broken on at least Lime2, BananaPi and Cubieboard2 since
v4.5 [0], including all five stable releases :(
The v4.5 patches quoted above are already +4 weeks old, could we
please get them into stable?

Thanks!
Andre

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823493

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)

2016-05-20 Thread Giuseppe CAVALLARO 

Hello

On 5/20/2016 9:56 AM, Marc Zyngier wrote:

On 20/05/16 06:44, Andre Heider wrote:

Giuseppe, Alexandre, et al.,

On Thu, Mar 17, 2016 at 8:52 AM, Marc Zyngier  wrote:

On Thu, 17 Mar 2016 00:56:40 +0100
Bert Lindner  wrote:

On 2016-03-16 18:42, Marc Zyngier wrote:

On 16/03/16 15:10, Bert Lindner wrote:

On 2016-03-16 14:10, Andreas Färber wrote:

Am 16.03.2016 um 13:09 schrieb Robin Murphy:

On 16/03/16 11:39, Marc Zyngier wrote:

On 16/03/16 11:19, Bert Lindner wrote:

...

For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
with the eth0 PHY in mainline kernel 4.5.0 that developed since
4.5.0-rc7. Ethernet does not work, although eth0 is reported:

...

[9.767125] NET: Registered protocol family 10
[   10.357405] libphy: PHY stmmac-0: not found
[   10.362382] eth0: Could not attach to PHY
[   10.366557] stmmac_open: Cannot attach to PHY (error: -19)

...

v4 fixes for 4.5 are here:

https://patchwork.ozlabs.org/patch/598195/ (revert)
https://patchwork.ozlabs.org/patch/598196/

...

Good to know, thanks. Could you also give the potential fix a go (as
mentioned by Andreas)? Just to make sure that whatever gets merged next
will actually fix the issue.


Yes sure, it took a while because I had to travel. Confirmed, the
v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:

root@lime2-079f:~# cat /proc/version
Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC 2016

dmesg:
[8.245273] NET: Registered protocol family 10
[9.297406]  RX IPC Checksum Offload disabled
[9.297460]  No MAC Management Counters available
[9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   16.285658] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
1Gbps/Full - flow control rx/tx
[   16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

The board is connected to my laptop rather than to a switch, so that
might be where the flow control message comes from (not sure). Anyway
ethernet works.


Cool, many thanks for taking the time to test and report.

Hopefully Giuseppe will get this merged quickly enough in mainline, and
it should then trickle into a 4.5-stable release (cc-ing stable on
these patches would probably be a good idea, BTW).


stmmac is broken on at least Lime2, BananaPi and Cubieboard2 since
v4.5 [0], including all five stable releases :(


All the A20 platforms are dead, actually.


The v4.5 patches quoted above are already +4 weeks old, could we
please get them into stable?


For that, the maintainer would have needed to CC stable, which he
didn't. I'd expect someone who cares to send these patches to stable.
It'd be better if the maintainer would do it himself though.


sure, I can send the patches to stable (sorry if I missed to add
stable ML on CC).

Andre, I have not clear if the train of patches actually fix the
issue or if you need my support to fix something else. In that case
I need some input for debugging (e.g. kernel log).

let me know, is it enough to re-send the patches only?

Regards
Peppe



Thanks,

M.



--
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.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)

2016-05-20 Thread Marc Zyngier 
On 20/05/16 06:44, Andre Heider wrote:
> Giuseppe, Alexandre, et al.,
> 
> On Thu, Mar 17, 2016 at 8:52 AM, Marc Zyngier  wrote:
>> On Thu, 17 Mar 2016 00:56:40 +0100
>> Bert Lindner  wrote:
>>> On 2016-03-16 18:42, Marc Zyngier wrote:
 On 16/03/16 15:10, Bert Lindner wrote:
> On 2016-03-16 14:10, Andreas Färber wrote:
>> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>>> On 16/03/16 11:39, Marc Zyngier wrote:
 On 16/03/16 11:19, Bert Lindner wrote:
> ...
> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
> with the eth0 PHY in mainline kernel 4.5.0 that developed since
> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
> ...
> [9.767125] NET: Registered protocol family 10
> [   10.357405] libphy: PHY stmmac-0: not found
> [   10.362382] eth0: Could not attach to PHY
> [   10.366557] stmmac_open: Cannot attach to PHY (error: -19)
> ...
>> v4 fixes for 4.5 are here:
>>
>> https://patchwork.ozlabs.org/patch/598195/ (revert)
>> https://patchwork.ozlabs.org/patch/598196/
> ...
 Good to know, thanks. Could you also give the potential fix a go (as
 mentioned by Andreas)? Just to make sure that whatever gets merged next
 will actually fix the issue.
>>>
>>> Yes sure, it took a while because I had to travel. Confirmed, the
>>> v4-for-4.5 fix works well for me, on sun7i-a20-olinuxino-lime2:
>>>
>>> root@lime2-079f:~# cat /proc/version
>>> Linux version 4.5.0-598195-598196-v4 (root@lime2-079f) (gcc version
>>> 4.9.1 (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Wed Mar 16 16:44:22 UTC 2016
>>>
>>> dmesg:
>>> [8.245273] NET: Registered protocol family 10
>>> [9.297406]  RX IPC Checksum Offload disabled
>>> [9.297460]  No MAC Management Counters available
>>> [9.297951] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> [   16.285658] sun7i-dwmac 1c5.ethernet eth0: Link is Up -
>>> 1Gbps/Full - flow control rx/tx
>>> [   16.285798] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>
>>> The board is connected to my laptop rather than to a switch, so that
>>> might be where the flow control message comes from (not sure). Anyway
>>> ethernet works.
>>
>> Cool, many thanks for taking the time to test and report.
>>
>> Hopefully Giuseppe will get this merged quickly enough in mainline, and
>> it should then trickle into a 4.5-stable release (cc-ing stable on
>> these patches would probably be a good idea, BTW).
> 
> stmmac is broken on at least Lime2, BananaPi and Cubieboard2 since
> v4.5 [0], including all five stable releases :(

All the A20 platforms are dead, actually.

> The v4.5 patches quoted above are already +4 weeks old, could we
> please get them into stable?

For that, the maintainer would have needed to CC stable, which he
didn't. I'd expect someone who cares to send these patches to stable.
It'd be better if the maintainer would do it himself though.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

-- 
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.
For more options, visit https://groups.google.com/d/optout.