[PATCH] net: vrf: replace hard tab with space in assignment

2016-06-20 Thread Chris Packham
The assignment of rth->dst.output in vrf_rt6_create() and
vrf_rtable_create() used a hard tab before the '='. The neighboring
assignments did not. Make the assignment of rth->dst.output consistent
with the surrounding code.

Signed-off-by: Chris Packham 
---
 drivers/net/vrf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index dff08842f26d..8bd8c7e1ee87 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -304,7 +304,7 @@ static int vrf_rt6_create(struct net_device *dev)
dst_hold(&rt6->dst);
 
rt6->rt6i_table = rt6i_table;
-   rt6->dst.output = vrf_output6;
+   rt6->dst.output = vrf_output6;
rcu_assign_pointer(vrf->rt6, rt6);
 
rc = 0;
@@ -403,7 +403,7 @@ static int vrf_rtable_create(struct net_device *dev)
if (!rth)
return -ENOMEM;
 
-   rth->dst.output = vrf_output;
+   rth->dst.output = vrf_output;
rth->rt_table_id = vrf->tb_id;
 
rcu_assign_pointer(vrf->rth, rth);
-- 
2.8.4



[PATCH] ARM: dts: armada-38x: Add NAND pinctrl information

2016-08-23 Thread Chris Packham
Add pin control information for the NAND flash interface. This interface
is multiplexed with the device bus interface to the function is "dev"
not "nand" as one might expect.

Signed-off-by: Chris Packham 
---
 arch/arm/boot/dts/armada-38x.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
b/arch/arm/boot/dts/armada-38x.dtsi
index 3312be6c82cc..30381d421d43 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -287,6 +287,15 @@
marvell,function = "spi1";
};
 
+   nand_pins: nand-pins {
+   marvell,pins = "mpp22", "mpp34", 
"mpp23",
+  "mpp33", "mpp38", 
"mpp28",
+  "mpp40", "mpp42", 
"mpp35",
+  "mpp36", "mpp25", 
"mpp30",
+  "mpp32";
+   marvell,function = "dev";
+   };
+
uart0_pins: uart-pins-0 {
marvell,pins = "mpp0", "mpp1";
marvell,function = "ua0";
-- 
2.9.2.518.ged577c6.dirty



[PATCH] switchdev: documentation: minor typo fixes

2017-08-17 Thread Chris Packham
Two typos in switchdev.txt

Signed-off-by: Chris Packham 
---
 Documentation/networking/switchdev.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/switchdev.txt 
b/Documentation/networking/switchdev.txt
index 3e7b946dea27..5e40e1f68873 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -228,7 +228,7 @@ Learning on the device port should be enabled, as well as 
learning_sync:
bridge link set dev DEV learning on self
bridge link set dev DEV learning_sync on self
 
-Learning_sync attribute enables syncing of the learned/forgotton FDB entry to
+Learning_sync attribute enables syncing of the learned/forgotten FDB entry to
 the bridge's FDB.  It's possible, but not optimal, to enable learning on the
 device port and on the bridge port, and disable learning_sync.
 
@@ -245,7 +245,7 @@ the responsibility of the port driver/device to age out 
these entries.  If the
 port device supports ageing, when the FDB entry expires, it will notify the
 driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL.  If the
 device does not support ageing, the driver can simulate ageing using a
-garbage collection timer to monitor FBD entries.  Expired entries will be
+garbage collection timer to monitor FDB entries.  Expired entries will be
 notified to the bridge using SWITCHDEV_FDB_DEL.  See rocker driver for
 example of driver running ageing timer.
 
-- 
2.14.1



Re: [PATCH v3 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants.

2017-10-15 Thread Chris Packham
Hi Boris,

On 15/10/17 02:13, Boris Brezillon wrote:
> Hi Kalyan,
> 
> On Thu, 28 Sep 2017 13:57:56 +1300
> Kalyan Kinthada  wrote:
> 
>> When the arbitration between NOR and NAND flash is enabled
>> the  field bit[21] in the Data Flash Control Register
>> needs to be set to 1 according to guidleine GL-5830741 mentioned
>> in Marvell Errata document MV-S501377-00, Rev. D.
> 
> The real question is, is this patch fixing a real bug or are you just
> setting this bit because a guideline says it should be set?

Yes that's a fair summary. It is in a document called "Functional 
Errata" so there is some feeling here that we (allied telesis) should 
follow up things in these kinds of documents.

> As far as I
> understand, noone fully understands what this bit does and why it needs
> to be set, so if you're not fixing a real bug, I'd prefer keeping the
> code unchanged code until someone complains for a good reason.

Agreed. We've certainly not noticed a change in behaviour on our boards. 
I've requested more information from Marvell through their support 
channels. I'll share what I can if/when they come back with something 
useful.

> 
> Regards,
> 
> Boris
> 
>>
>> This commit sets the FORCE_CSX bit to 1 for all
>> ARMADA370 variants as the arbitration is always enabled by default.
>> This change does not apply for pxa3xx variants because the FORCE_CSX
>> bit does not exist/reserved on the NFCv1.
>>
>> The NDCR_ND_MODE conflicts with the new NDCR_FORCE_CSX but is unused so
>> remove it along with NDCR_NAND_MODE.
>>
>> Signed-off-by: Kalyan Kinthada 
>> ---
>>   drivers/mtd/nand/pxa3xx_nand.c | 9 +++--
>>   1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
>> index 85cff68643e0..a6a7a5af7bed 100644
>> --- a/drivers/mtd/nand/pxa3xx_nand.c
>> +++ b/drivers/mtd/nand/pxa3xx_nand.c
>> @@ -67,8 +67,7 @@
>>   #define NDCR_DWIDTH_M  (0x1 << 26)
>>   #define NDCR_PAGE_SZ   (0x1 << 24)
>>   #define NDCR_NCSX  (0x1 << 23)
>> -#define NDCR_ND_MODE(0x3 << 21)
>> -#define NDCR_NAND_MODE  (0x0)
>> +#define NDCR_FORCE_CSX  (0x1 << 21)
>>   #define NDCR_CLR_PG_CNT(0x1 << 20)
>>   #define NFCV1_NDCR_ARB_CNTL(0x1 << 19)
>>   #define NFCV2_NDCR_STOP_ON_UNCOR   (0x1 << 19)
>> @@ -1464,6 +1463,9 @@ static int pxa3xx_nand_config_ident(struct 
>> pxa3xx_nand_info *info)
>>  info->chunk_size = PAGE_CHUNK_SIZE;
>>  info->reg_ndcr = 0x0; /* enable all interrupts */
>>  info->reg_ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : 0;
>> +/* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: GL-5830741 */
>> +if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
>> +info->reg_ndcr |= NDCR_FORCE_CSX;
>>  info->reg_ndcr |= NDCR_RD_ID_CNT(READ_ID_BYTES);
>>  info->reg_ndcr |= NDCR_SPARE_EN;
>>   
>> @@ -1498,6 +1500,9 @@ static void pxa3xx_nand_detect_config(struct 
>> pxa3xx_nand_info *info)
>>  info->reg_ndcr = ndcr &
>>  ~(NDCR_INT_MASK | NDCR_ND_ARB_EN | NFCV1_NDCR_ARB_CNTL);
>>  info->reg_ndcr |= (pdata->enable_arbiter) ? NDCR_ND_ARB_EN : 0;
>> +/* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#: GL-5830741 */
>> +if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
>> +info->reg_ndcr |= NDCR_FORCE_CSX;
>>  info->ndtr0cs0 = nand_readl(info, NDTR0CS0);
>>  info->ndtr1cs0 = nand_readl(info, NDTR1CS0);
>>   }
> 
> 



[PATCH v3 1/3] EDAC: mv64x60: check driver registration success

2017-05-29 Thread Chris Packham
Check the return status of platform_driver_register() in
mv64x60_edac_init(). Only output messages and initialise the
edac_op_state if the registration is successful.

Signed-off-by: Chris Packham 
---
Changes in v3:
- catch the retval of platform_register_drivers and return early on failure
  (thanks Borislav).

 drivers/edac/mv64x60_edac.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index 14b7e7b71eaa..172081551a70 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -853,7 +853,11 @@ static struct platform_driver * const drivers[] = {
 
 static int __init mv64x60_edac_init(void)
 {
-   int ret = 0;
+   int ret;
+
+   ret = platform_register_drivers(drivers, ARRAY_SIZE(drivers));
+   if (ret)
+   return ret;
 
printk(KERN_INFO "Marvell MV64x60 EDAC driver " MV64x60_REVISION "\n");
printk(KERN_INFO "\t(C) 2006-2007 MontaVista Software\n");
@@ -867,7 +871,7 @@ static int __init mv64x60_edac_init(void)
break;
}
 
-   return platform_register_drivers(drivers, ARRAY_SIZE(drivers));
+   return 0;
 }
 module_init(mv64x60_edac_init);
 
-- 
2.13.0



[PATCH v3 3/3] EDAC: mv64x60: replace in_le32/out_le32 with readl/writel

2017-05-29 Thread Chris Packham
To allow this driver to be used on non-powerpc platforms it needs to use
io accessors suitable for all platforms.

Signed-off-by: Chris Packham 
---
Changes in v2:
- use readl/writel as suggested.
Changes in v3:
- None

 drivers/edac/mv64x60_edac.c | 84 ++---
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index 4511fbf9fdd1..004b208752bf 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -32,21 +32,21 @@ static void mv64x60_pci_check(struct edac_pci_ctl_info *pci)
struct mv64x60_pci_pdata *pdata = pci->pvt_info;
u32 cause;
 
-   cause = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+   cause = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
if (!cause)
return;
 
printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
printk(KERN_ERR "Cause register: 0x%08x\n", cause);
printk(KERN_ERR "Address Low: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
+  readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
printk(KERN_ERR "Address High: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
+  readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
printk(KERN_ERR "Attribute: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
+  readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
printk(KERN_ERR "Command: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, ~cause);
+  readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
+   writel(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
 
if (cause & MV64X60_PCI_PE_MASK)
edac_pci_handle_pe(pci, pci->ctl_name);
@@ -61,7 +61,7 @@ static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
struct mv64x60_pci_pdata *pdata = pci->pvt_info;
u32 val;
 
-   val = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+   val = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
if (!val)
return IRQ_NONE;
 
@@ -93,7 +93,7 @@ static int __init mv64x60_pci_fixup(struct platform_device 
*pdev)
if (!pci_serr)
return -ENOMEM;
 
-   out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+   writel(readl(pci_serr) & ~0x1, pci_serr);
iounmap(pci_serr);
 
return 0;
@@ -161,10 +161,10 @@ static int mv64x60_pci_err_probe(struct platform_device 
*pdev)
goto err;
}
 
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, 0);
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK, 0);
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK,
-MV64X60_PCIx_ERR_MASK_VAL);
+   writel(0, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+   writel(0, pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
+   writel(MV64X60_PCIx_ERR_MASK_VAL,
+ pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
 
if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
edac_dbg(3, "failed edac_pci_add_device()\n");
@@ -233,23 +233,23 @@ static void mv64x60_sram_check(struct 
edac_device_ctl_info *edac_dev)
struct mv64x60_sram_pdata *pdata = edac_dev->pvt_info;
u32 cause;
 
-   cause = in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
+   cause = readl(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
if (!cause)
return;
 
printk(KERN_ERR "Error in internal SRAM\n");
printk(KERN_ERR "Cause register: 0x%08x\n", cause);
printk(KERN_ERR "Address Low: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
+  readl(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
printk(KERN_ERR "Address High: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_HI));
+  readl(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_HI));
printk(KERN_ERR "Data Low: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_LO));
+  readl(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_LO));
printk(KERN_ERR "Data High: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_HI));
+  readl(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_HI));
printk(KERN_ERR "Parity: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_PARITY));
-   out_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE, 0);
+  

[PATCH v3 0/3] EDAC: mv64x60: updates

2017-05-29 Thread Chris Packham
I'm looking at making use of the mv64x60_edac driver for the armada processors.
It appears that at least the DRAM ECC error reporting is the same block from
the old Marvell Discovery class of processors. On the ARM side I need to get
the error interrupts exposed first before I can send my second set of changes
for this driver but this first set is just a series of cleanups.

Chris Packham (3):
  EDAC: mv64x60: check driver registration success
  EDAC: mv64x60: Fix pdata->name
  EDAC: mv64x60: replace in_le32/out_le32 with readl/writel

 drivers/edac/mv64x60_edac.c | 94 +++--
 1 file changed, 49 insertions(+), 45 deletions(-)

-- 
2.13.0



[PATCH v3 2/3] EDAC: mv64x60: Fix pdata->name

2017-05-29 Thread Chris Packham
Change this from mpc85xx_pci_err to mv64x60_pci_err.  The former is
likely a hangover from when this driver was created.

Signed-off-by: Chris Packham 
---
Changes in v3:
- None

 drivers/edac/mv64x60_edac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index 172081551a70..4511fbf9fdd1 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -116,7 +116,7 @@ static int mv64x60_pci_err_probe(struct platform_device 
*pdev)
pdata = pci->pvt_info;
 
pdata->pci_hose = pdev->id;
-   pdata->name = "mpc85xx_pci_err";
+   pdata->name = "mv64x60_pci_err";
platform_set_drvdata(pdev, pci);
pci->dev = &pdev->dev;
pci->dev_name = dev_name(&pdev->dev);
-- 
2.13.0



Re: [PATCH v3 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants.

2017-10-30 Thread Chris Packham
Hi Miquel,

On 09/10/17 19:19, Miquel RAYNAL wrote:
> Hello Kalyan,
> 
> On Mon, 9 Oct 2017 02:31:30 +
> Kalyan Kinthada  wrote:
> 
>> On 05/10/17 20:41, Miquel RAYNAL wrote:
>>> Hello Kalyan,
>>>
>>> On Thu, 28 Sep 2017 13:57:56 +1300
>>> Kalyan Kinthada  wrote:
>>>   
 When the arbitration between NOR and NAND flash is enabled
 the  field bit[21] in the Data Flash Control Register
 needs to be set to 1 according to guidleine GL-5830741 mentioned
>>> Typo: guideline ^
>> I will correct this typo in the next patch version.
 in Marvell Errata document MV-S501377-00, Rev. D.
>>> Thanks for that, I checked it.
>>>   
 This commit sets the FORCE_CSX bit to 1 for all
 ARMADA370 variants as the arbitration is always enabled by default.
 This change does not apply for pxa3xx variants because the
 FORCE_CSX bit does not exist/reserved on the NFCv1.
>>> Sorry to bother you again but I am reworking the pxa3xx_nand driver
>>> and so I would like to deeply understand why this is needed because
>>> I will have to integrate it in my work too.
>>>
>>> So please tell me what is your setup, do you really use NAND/NOR
>>> arbitration? Do you have not-Don't Care CS NAND chips? I have some
>>> doubts because even if the spec precises in the NAND controller
>>> chapter that arbitration is always enabled by default, the bit 27
>>> (NfArbiterEn) in the SoC Device Multiplex Register at offset
>>> 0x00018208 is actually at 0 by default (disabled). Did you enable
>>> this bit manually ? I checked with devmem on my setup and this bit
>>> was unset.
>> Yes, my setup use NAND/NOR arbitration and use a Don't
>> care CS Nand Chip. The bit 27 at offset 0x00018208 is set to 1
>> by default in my case. I did not manually set the bit 27 to 1.
> 
> Actually if you use Don't Care CS NAND chips you should not need the
> force CS bit, as it is mentioned in the guidelines you pointed, this
> bit is only useful for *not* don't care CS NAND chips (and the name
> "force CS" is pretty straight forward too!).

It's less straight forward than you think. It's FORCE_CSX (the X is 
important) which is defined as "force chip select false on busy". What 
it means is that the NF_CSn is de-asserted if the interface is 
arbitrated away from the NAND flash controller. I think that means you 
won't end up with the chip-select for the dev-bus/NOR firing immediately 
when that device is arbitrated.

> Otherwise what bootloader and kernel do you use to have this
> bit set by default? You may also want to check if this bit is set by
> your bootloader by stopping it before it loads Linux and check manually
> the value of this bit with 'md' (on U-Boot).
> 
> Thank you,
> Miquèl
> 
>>
>> Please let me now if you have any other question or do you want me
>> to send the updated patch version with the typo fixed.
>>
>> Thank You,
>> Kalyan
>>
>>>
>>> Thank you for your time,
>>> Miquèl
>>>   
 The NDCR_ND_MODE conflicts with the new NDCR_FORCE_CSX but is
 unused so remove it along with NDCR_NAND_MODE.

 Signed-off-by: Kalyan Kinthada
  ---
>>>
>>>   
drivers/mtd/nand/pxa3xx_nand.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)

 diff --git a/drivers/mtd/nand/pxa3xx_nand.c
 b/drivers/mtd/nand/pxa3xx_nand.c index 85cff68643e0..a6a7a5af7bed
 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c
 +++ b/drivers/mtd/nand/pxa3xx_nand.c
 @@ -67,8 +67,7 @@
#define NDCR_DWIDTH_M   (0x1 << 26)
#define NDCR_PAGE_SZ(0x1 << 24)
#define NDCR_NCSX   (0x1 << 23)
 -#define NDCR_ND_MODE  (0x3 << 21)
 -#define NDCR_NAND_MODE(0x0)
 +#define NDCR_FORCE_CSX(0x1 << 21)
#define NDCR_CLR_PG_CNT (0x1 << 20)
#define NFCV1_NDCR_ARB_CNTL (0x1 << 19)
#define NFCV2_NDCR_STOP_ON_UNCOR(0x1 << 19)
 @@ -1464,6 +1463,9 @@ static int pxa3xx_nand_config_ident(struct
 pxa3xx_nand_info *info) info->chunk_size = PAGE_CHUNK_SIZE;
info->reg_ndcr = 0x0; /* enable all interrupts */
info->reg_ndcr |= (pdata->enable_arbiter) ?
 NDCR_ND_ARB_EN : 0;
 +  /* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#:
 GL-5830741 */
 +  if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
 +  info->reg_ndcr |= NDCR_FORCE_CSX;
info->reg_ndcr |= NDCR_RD_ID_CNT(READ_ID_BYTES);
info->reg_ndcr |= NDCR_SPARE_EN;

 @@ -1498,6 +1500,9 @@ static void pxa3xx_nand_detect_config(struct
 pxa3xx_nand_info *info) info->reg_ndcr = ndcr &
~(NDCR_INT_MASK | NDCR_ND_ARB_EN |
 NFCV1_NDCR_ARB_CNTL); info->reg_ndcr |= (pdata->enable_arbiter) ?
 NDCR_ND_ARB_EN : 0;
 +  /* Set FORCE_CSX bit for all ARMADA370 Variants. Ref#:
 GL-5830741 */
 +  if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370)
 +  info->reg_ndcr |= NDCR_FORCE_CSX;
inf

Re: [PATCH] arm_pmu: fix compiler warning in arm_pmu_device_probe

2018-08-02 Thread Chris Packham
On 02/08/18 23:05, Will Deacon wrote:
> On Thu, Aug 02, 2018 at 09:45:26AM +1200, Chris Packham wrote:
>> GCC warns
>>
>>arm_pmu_platform.c:234:5: error: 'err' may be used uninitialized in this 
>> function [-Werror=maybe-uninitialized]
>>
>> This is because we rely on the for_each_cpu loop in armpmu_request_irqs
>> to initialise err. The warning is a little bogus because we know if
>> there were 0 CPUs this code would not be running.
>>
>> Initialise err to 0 to avoid the warning.
>>
>> Signed-off-by: Chris Packham 
>> ---
>> This has been reported before in https://lkml.org/lkml/2018/3/5/508 I'm not
>> sure if it was dismmissed as "meh, gcc is wrong" or if it was just wainting 
>> for
>> someone with some round tuits.
> 
> Which version of GCC are you using? I don't see this warning locally.
> 

My local cross-compiler is

$ arm-softfloat-linux-gnueabi-gcc --version
arm-softfloat-linux-gnueabi-gcc (crosstool-NG crosstool-ng-1.22.0) 4.9.3

Old-ish but as far as I was aware still supported for building the kernel.

I've just tried 7.3.0 and 8.1.0 neither of which complain.

A quick look at the report linked to above seems they probably were 
using 4.6.3 and it still appears in current build reports

http://kisskb.ellerman.id.au/kisskb/buildresult/13455291/






Re: [PATCH v3 1/4] mtd: rawnand: marvell: Handle on-die ECC

2018-06-20 Thread Chris Packham
On 20/06/18 19:47, Boris Brezillon wrote:
> Hi Chris,
> 
> On Wed, 20 Jun 2018 17:05:41 +1200
> Chris Packham  wrote:
> 
>>  From the controllers point of view this is the same as no or
>> software only ECC.
>>
>> Reviewed-by: Boris Brezillon 
> 
> I'm nitpicking, but we usually put the R-b/A-b tags after the author
> SoB.

Yeah sorry force of habit from using gerrit internally. I'll try to 
re-train my fingers.

>> Signed-off-by: Chris Packham 
>> ---
>> Changes in v2:
>> - New
>> Changes in v3:
>> - Add review from Boris
>>
>>   drivers/mtd/nand/raw/marvell_nand.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/nand/raw/marvell_nand.c 
>> b/drivers/mtd/nand/raw/marvell_nand.c
>> index ebb1d141b900..ba6889bbe802 100644
>> --- a/drivers/mtd/nand/raw/marvell_nand.c
>> +++ b/drivers/mtd/nand/raw/marvell_nand.c
>> @@ -2157,6 +2157,7 @@ static int marvell_nand_ecc_init(struct mtd_info *mtd,
>>  break;
>>  case NAND_ECC_NONE:
>>  case NAND_ECC_SOFT:
>> +case NAND_ECC_ON_DIE:
>>  if (!nfc->caps->is_nfcv2 && mtd->writesize != SZ_512 &&
>>  mtd->writesize != SZ_2K) {
>>  dev_err(nfc->dev, "NFCv1 cannot write %d bytes pages\n",
> 
> 



Re: [PATCH v3 3/4] mtd: rawnand: micron: add fixup for ONFI revision

2018-06-20 Thread Chris Packham
On 20/06/18 19:54, Boris Brezillon wrote:
> On Wed, 20 Jun 2018 17:05:43 +1200
> Chris Packham  wrote:
> 
>> Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
>> revision number field of the ONFI parameter page. Rather than rejecting
>> these outright assume ONFI version 1.0 if the revision number is 00 00.
>>
>> Reviewed-by: Boris Brezillon 
>> Signed-off-by: Chris Packham 
>> ---
>> This is now qualified on vendor == MICRON. I haven't qualified this
>> based on specific chips the ABAFA (id=d1) and ABBFA (id=a1) variants are
>> documented to have this behaviour.
>>
>> Changes in v2:
>> - use fixup_onfi_param_page
>> Changes in v3:
>> - add code comment next to workaround
>>
>>   drivers/mtd/nand/raw/nand_micron.c | 13 +
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/raw/nand_micron.c 
>> b/drivers/mtd/nand/raw/nand_micron.c
>> index 5ec4c90a637d..5cec79372181 100644
>> --- a/drivers/mtd/nand/raw/nand_micron.c
>> +++ b/drivers/mtd/nand/raw/nand_micron.c
>> @@ -289,6 +289,19 @@ static int micron_nand_init(struct nand_chip *chip)
>>  return 0;
>>   }
>>   
>> +static void micron_fixup_onfi_param_page(struct nand_chip *chip,
>> + struct nand_onfi_params *p)
>> +{
>> +/*
>> + * MT29F1G08ABAFAWP-ITE:F and possibly others report 00 00 for the
>> + * revision number field of the ONFI parameter page. Assume ONFI
>> + * version 1.0 if the revision number is 00 00.
>> + */
>> +if (le16_to_cpu(p->revision) == 0)
>> +p->revision = cpu_to_le16(1 << 1);
> 
> Would be better to have macros defining all version numbers in rawnand.h
> 
> #define ONFI_VERSION_1_0  BIT(1)
> #define ONFI_VERSION_2_0  BIT(2)
> #define ONFI_VERSION_2_1  BIT(3)
> #define ONFI_VERSION_2_2  BIT(4)
> #define ONFI_VERSION_2_3  BIT(5)
> #define ONFI_VERSION_3_0  BIT(6)
> #define ONFI_VERSION_3_1  BIT(7)
> #define ONFI_VERSION_3_2  BIT(8)
> #define ONFI_VERSION_4_0  BIT(9)
> 

Make sense. Do you want me to do so in a v4 or send a new patch and 
clean up the other uses?

>> +}
>> +
>>   const struct nand_manufacturer_ops micron_nand_manuf_ops = {
>>  .init = micron_nand_init,
>> +.fixup_onfi_param_page = micron_fixup_onfi_param_page,
>>   };
> 
> 



Re: [PATCH v3 4/4] mtd: rawnand: micron: support 8/512 on-die ECC

2018-06-20 Thread Chris Packham
On 20/06/18 20:02, Boris Brezillon wrote:
> On Wed, 20 Jun 2018 17:05:44 +1200
> Chris Packham  wrote:
> 
>> Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
>> per 512 bytes. Add support for this combination.
>>
>> Signed-off-by: Chris Packham 
>> ---
>> Changes in v2:
>> - New
>> Changes in v3:
>> - Handle reporting of corrected errors that don't require a rewrite, expand
>>comment for the ECC status bits.
>>
>>   drivers/mtd/nand/raw/nand_micron.c | 34 --
>>   1 file changed, 27 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/raw/nand_micron.c 
>> b/drivers/mtd/nand/raw/nand_micron.c
>> index 5cec79372181..0c2bde4411d7 100644
>> --- a/drivers/mtd/nand/raw/nand_micron.c
>> +++ b/drivers/mtd/nand/raw/nand_micron.c
>> @@ -18,10 +18,24 @@
>>   #include 
>>   
>>   /*
>> - * Special Micron status bit that indicates when the block has been
>> - * corrected by on-die ECC and should be rewritten
>> + * Special Micron status bit 3 indicates that the block has been
>> + * corrected by on-die ECC and should be rewritten.
>> + *
>> + * On chips with 8-bit ECC and additional bit can be used to distinguish
>> + * cases where a errors were corrected without needing a rewrite
>> + *
>> + * Bit 4 Bit 3 Bit 0 Description
>> + * - - - ---
>> + * 0 0 0 No Errors
>> + * 0 0 1 Multiple uncorrected errors
>> + * 0 1 0 4 - 6 errors corrected, recommend rewrite
>> + * 0 0 1 Reserved
>> + * 1 0 0 1 - 3 errors corrected
>> + * 1 0 1 Reserved
>> + * 1 1 0 7 - 8 errors corrected, recommend rewrite
>>*/
>>   #define NAND_STATUS_WRITE_RECOMMENDED  BIT(3)
>> +#define NAND_STATUS_ERRORS_CORRECTEDBIT(4)
>>   
>>   struct nand_onfi_vendor_micron {
>>  u8 two_plane_read;
>> @@ -141,7 +155,7 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, 
>> struct nand_chip *chip,
>>  mtd->ecc_stats.failed++;
>>   
>>  /*
>> - * The internal ECC doesn't tell us the number of bitflips
>> + * The internal 4-bit ECC doesn't tell us the number of bitflips
>>   * that have been corrected, but tells us if it recommends to
>>   * rewrite the block. If it's the case, then we pretend we had
>>   * a number of bitflips equal to the ECC strength, which will
>> @@ -149,6 +163,12 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, 
>> struct nand_chip *chip,
>>   */
>>  else if (status & NAND_STATUS_WRITE_RECOMMENDED)
>>  max_bitflips = chip->ecc.strength;
>> +/*
>> + * Chips with 8-bit internal ECC do tell us if errors 1 to 3 bit
>> + * errors have been corrected without recommending a rewrite.
>> + */
>> +else if (status & NAND_STATUS_ERRORS_CORRECTED)
>> +max_bitflips = 3;
> 
> Why not masking bit 3, 4 and 0 and having a switch-case block?

Mainly because the existing code was just checking bit 3 and that 
happened to worked for my use-case.

I'm happy to re-work it as you've suggested can anyone point me at the 
datasheet for a 4/512 on-die chip (or just the part number I can lookup 
on mircon's site).

> 
> Also, you should update ecc_stats.corrected (see the patch I just sent
> [1]).
> 

Will do. I'll pull in your patch and base v4 on top of that.

>>   
>>  ret = nand_read_data_op(chip, buf, mtd->writesize, false);
>>  if (!ret && oob_required)
>> @@ -240,9 +260,9 @@ static int micron_supports_on_die_ecc(struct nand_chip 
>> *chip)
>>   
>>  /*
>>   * Some Micron NANDs have an on-die ECC of 4/512, some other
>> - * 8/512. We only support the former.
>> + * 8/512.
>>   */
>> -if (chip->ecc_strength_ds != 4)
>> +if (chip->ecc_strength_ds != 4 && chip->ecc_strength_ds != 8)
>>  return MICRON_ON_DIE_UNSUPPORTED;

I was thinking about removing this. The original code excluded 8/512 due 
to lack of access to a chip that implements this, which I now have.

> Given that our on-die-support detection procedure is not reliable, I'd
> recommend changing the way we do it and instead base this detection
> logic on the model name (in the ONFI param page) or the READ_ID bytes.
> 

The problem is I don't know an exhaustive list of IDs that this applies 
to. I guess having a list of known IDs and falling back to the current 
detecti

[PATCH v4 6/6] mtd: rawnand: micron: detect forced on-die ECC

2018-06-21 Thread Chris Packham
Some Micron NAND chips have on-die ECC forceably enabled. The detect
these based on chip ID as there seems to be no other way of
distinguishing these chips from those that have optional support for
on-die ECC.

When a chip with mandatory on-die ECC is detected change the current ECC
mode to on-die.

Signed-off-by: Chris Packham 
---
I'm not convinced that just changing chip->ecc.mode is sensible. An
alternative I considered was only proceeding if the ecc.mode is set to
ON_DIE.

Changes in v4:
- New

 drivers/mtd/nand/raw/nand_micron.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index f1ecd4986b50..9ba9007a9a06 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -227,6 +227,14 @@ enum {
MICRON_ON_DIE_MANDATORY,
 };
 
+/*
+ * These parts are known to have on-die ECC forceably enabled
+ */
+static u8 micron_on_die_ecc[] = {
+   0xd1, /* MT29F1G08ABAFA */
+   0xa1, /* MT29F1G08ABBFA */
+};
+
 /*
  * Try to detect if the NAND support on-die ECC. To do this, we enable
  * the feature, and read back if it has been enabled as expected. We
@@ -241,6 +249,11 @@ static int micron_supports_on_die_ecc(struct nand_chip 
*chip)
 {
u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = { 0, };
int ret;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(micron_on_die_ecc); i++)
+   if (chip->id.data[1] == micron_on_die_ecc[i])
+   return MICRON_ON_DIE_MANDATORY;
 
if (!chip->parameters.onfi.version)
return MICRON_ON_DIE_UNSUPPORTED;
@@ -289,8 +302,8 @@ static int micron_nand_init(struct nand_chip *chip)
ondie = micron_supports_on_die_ecc(chip);
 
if (ondie == MICRON_ON_DIE_MANDATORY) {
-   pr_err("On-die ECC forcefully enabled, not supported\n");
-   return -EINVAL;
+   pr_info("On-die ECC forcefully enabled\n");
+   chip->ecc.mode = NAND_ECC_ON_DIE;
}
 
if (chip->ecc.mode == NAND_ECC_ON_DIE) {
-- 
2.17.1



[PATCH v4 1/6] mtd: rawnand: marvell: Handle on-die ECC

2018-06-21 Thread Chris Packham
>From the controllers point of view this is the same as no or
software only ECC.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
Changes in v2:
- New
Changes in v3:
- Add review from Boris
Changes in v4:
- None

 drivers/mtd/nand/raw/marvell_nand.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/marvell_nand.c 
b/drivers/mtd/nand/raw/marvell_nand.c
index ebb1d141b900..ba6889bbe802 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -2157,6 +2157,7 @@ static int marvell_nand_ecc_init(struct mtd_info *mtd,
break;
case NAND_ECC_NONE:
case NAND_ECC_SOFT:
+   case NAND_ECC_ON_DIE:
if (!nfc->caps->is_nfcv2 && mtd->writesize != SZ_512 &&
mtd->writesize != SZ_2K) {
dev_err(nfc->dev, "NFCv1 cannot write %d bytes pages\n",
-- 
2.17.1



[PATCH v4 4/6] mtd: rawnand: micron: add fixup for ONFI revision

2018-06-21 Thread Chris Packham
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
This is now qualified on vendor == MICRON. I haven't qualified this
based on specific chips the ABAFA (id=d1) and ABBFA (id=a1) variants are
documented to have this behaviour.

Changes in v2:
- use fixup_onfi_param_page
Changes in v3:
- add code comment next to workaround
Changes in v4:
- use define for ONFI_VERSION

 drivers/mtd/nand/raw/nand_micron.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index 203faba0a9c1..d30bd4df9b12 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -290,6 +290,19 @@ static int micron_nand_init(struct nand_chip *chip)
return 0;
 }
 
+static void micron_fixup_onfi_param_page(struct nand_chip *chip,
+struct nand_onfi_params *p)
+{
+   /*
+* MT29F1G08ABAFAWP-ITE:F and possibly others report 00 00 for the
+* revision number field of the ONFI parameter page. Assume ONFI
+* version 1.0 if the revision number is 00 00.
+*/
+   if (le16_to_cpu(p->revision) == 0)
+   p->revision = cpu_to_le16(ONFI_VERSION_1_0);
+}
+
 const struct nand_manufacturer_ops micron_nand_manuf_ops = {
.init = micron_nand_init,
+   .fixup_onfi_param_page = micron_fixup_onfi_param_page,
 };
-- 
2.17.1



[PATCH v4 2/6] mtd: rawnand: add manufacturer fixup for ONFI parameter page

2018-06-21 Thread Chris Packham
This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.

Suggested-by: Boris Brezillon 
Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
Changes in v2:
- New
Changes in v3:
- Add doc comment and review from Boris
Changes in v4:
- None

 drivers/mtd/nand/raw/nand_base.c | 4 
 include/linux/mtd/rawnand.h  | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 0cd3e216b95c..65250308c82d 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5172,6 +5172,10 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
}
}
 
+   if (chip->manufacturer.desc && chip->manufacturer.desc->ops &&
+   chip->manufacturer.desc->ops->fixup_onfi_param_page)
+   chip->manufacturer.desc->ops->fixup_onfi_param_page(chip, p);
+
/* Check version */
val = le16_to_cpu(p->revision);
if (val & (1 << 5))
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 3e8ec3b8a39c..ef7e3b4e91ea 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -778,11 +778,14 @@ nand_get_sdr_timings(const struct nand_data_interface 
*conf)
  *   implementation) if any.
  * @cleanup: the ->init() function may have allocated resources, ->cleanup()
  *  is here to let vendor specific code release those resources.
+ * @fixup_onfi_param_page: apply vendor specific fixups to the ONFI
+ * parameter page. This is called after the checksum is verified.
  */
 struct nand_manufacturer_ops {
void (*detect)(struct nand_chip *chip);
int (*init)(struct nand_chip *chip);
void (*cleanup)(struct nand_chip *chip);
+   void (*fixup_onfi_param_page)(struct nand_chip *chip, struct 
nand_onfi_params *p);
 };
 
 /**
-- 
2.17.1



[PATCH v4 3/6] mtd: rawnand: add defines for ONFI version bits

2018-06-21 Thread Chris Packham
Add defines for the ONFI version bits and use them in
nand_flash_detect_onfi().

Signed-off-by: Chris Packham 
---
Changes in v4:
- New

 drivers/mtd/nand/raw/nand_base.c | 10 +-
 include/linux/mtd/rawnand.h  | 11 +++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 65250308c82d..36048e0cf1f5 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5178,15 +5178,15 @@ static int nand_flash_detect_onfi(struct nand_chip 
*chip)
 
/* Check version */
val = le16_to_cpu(p->revision);
-   if (val & (1 << 5))
+   if (val & ONFI_VERSION_2_3)
chip->parameters.onfi.version = 23;
-   else if (val & (1 << 4))
+   else if (val & ONFI_VERSION_2_2)
chip->parameters.onfi.version = 22;
-   else if (val & (1 << 3))
+   else if (val & ONFI_VERSION_2_1)
chip->parameters.onfi.version = 21;
-   else if (val & (1 << 2))
+   else if (val & ONFI_VERSION_2_0)
chip->parameters.onfi.version = 20;
-   else if (val & (1 << 1))
+   else if (val & ONFI_VERSION_1_0)
chip->parameters.onfi.version = 10;
 
if (!chip->parameters.onfi.version) {
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index ef7e3b4e91ea..015bc3f2fc13 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -230,6 +230,17 @@ enum nand_ecc_algo {
 /* Keep gcc happy */
 struct nand_chip;
 
+/* ONFI version bits */
+#define ONFI_VERSION_1_0   BIT(1)
+#define ONFI_VERSION_2_0   BIT(2)
+#define ONFI_VERSION_2_1   BIT(3)
+#define ONFI_VERSION_2_2   BIT(4)
+#define ONFI_VERSION_2_3   BIT(5)
+#define ONFI_VERSION_3_0   BIT(6)
+#define ONFI_VERSION_3_1   BIT(7)
+#define ONFI_VERSION_3_2   BIT(8)
+#define ONFI_VERSION_4_0   BIT(9)
+
 /* ONFI features */
 #define ONFI_FEATURE_16_BIT_BUS(1 << 0)
 #define ONFI_FEATURE_EXT_PARAM_PAGE(1 << 7)
-- 
2.17.1



[PATCH v4 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

2018-06-21 Thread Chris Packham
Hi,

I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.

This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but reports internally as ABAGA. Finally it has internal 8-bit ECC
which cannot be disabled.

The existing test in micron_supports_on_die_ecc() determines that on-die
ECC is supported but not mandatory but I know for this chip it is
mandatory despite what set_features returns.

In order for this to work I need to set nand-ecc-mode = "on-die" in my
dts. Ideally I'd like it to be automatic based on what the hardware can
support but that may be asking too much at the moment.

Here's a dump of the parameter page from the chip I have

: 4f 4e 46 49 00 00 18 00 3f 00 00 00 00 00 00 00 ONFI?...
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0020: 4d 49 43 52 4f 4e 20 20 20 20 20 20 4d 54 32 39  MICRON MT29
0030: 46 31 47 30 38 41 42 41 47 41 57 50 20 20 20 20  F1G08ABAGAWP
0040: 2c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ,...
0050: 00 08 00 00 80 00 00 02 00 00 20 00 40 00 00 00  ..  .@...
0060: 00 04 00 00 01 22 01 14 00 01 05 08 00 00 04 00 ."..
0070: 08 01 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 
0080: 08 3f 00 3f 00 58 02 10 27 46 00 64 00 00 00 00 .?.?.X..'F.d
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00a0: 00 00 00 00 01 00 00 00 00 02 04 80 01 81 04 03 
00b0: 02 01 1e 90 00 00 00 00 00 00 00 00 00 00 00 00 
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 85 a6 

Series changes in v3:
- No longer RFC
- dropped "mtd: rawnand: micron: add ONFI_FEATURE_ON_DIE_ECC to supported
  features" which Boris has already picked up
- dropped "mtd: rawnand: marvell: Support page size of 2048 with 8-bit ECC"
  since I can't test it.

Series changes in v4:
- based on top of http://patchwork.ozlabs.org/patch/932006/

Chris Packham (6):
  mtd: rawnand: marvell: Handle on-die ECC
  mtd: rawnand: add manufacturer fixup for ONFI parameter page
  mtd: rawnand: add defines for ONFI version bits
  mtd: rawnand: micron: add fixup for ONFI revision
  mtd: rawnand: micron: support 8/512 on-die ECC
  mtd: rawnand: micron: detect forced on-die ECC

 drivers/mtd/nand/raw/marvell_nand.c |  1 +
 drivers/mtd/nand/raw/nand_base.c| 14 +++--
 drivers/mtd/nand/raw/nand_micron.c  | 98 ++---
 include/linux/mtd/rawnand.h | 14 +
 4 files changed, 98 insertions(+), 29 deletions(-)

-- 
2.17.1



[PATCH v4 5/6] mtd: rawnand: micron: support 8/512 on-die ECC

2018-06-21 Thread Chris Packham
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
per 512 bytes. Add support for this combination.

Signed-off-by: Chris Packham 
---
Changes in v2:
- New
Changes in v3:
- Handle reporting of corrected errors that don't require a rewrite, expand
  comment for the ECC status bits.
Changes in v4:
- Use a switch statement for handling ECC status
- Update ecc_stats.corrected

 drivers/mtd/nand/raw/nand_micron.c | 68 --
 1 file changed, 46 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index d30bd4df9b12..f1ecd4986b50 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -18,10 +18,28 @@
 #include 
 
 /*
- * Special Micron status bit that indicates when the block has been
- * corrected by on-die ECC and should be rewritten
+ * Special Micron status bit 3 indicates that the block has been
+ * corrected by on-die ECC and should be rewritten.
+ *
+ * On chips with 8-bit ECC and additional bit can be used to distinguish
+ * cases where a errors were corrected without needing a rewrite
+ *
+ * Bit 4 Bit 3 Bit 0 Description
+ * - - - ---
+ * 0 0 0 No Errors
+ * 0 0 1 Multiple uncorrected errors
+ * 0 1 0 4 - 6 errors corrected, recommend rewrite
+ * 0 1 1 Reserved
+ * 1 0 0 1 - 3 errors corrected
+ * 1 0 1 Reserved
+ * 1 1 0 7 - 8 errors corrected, recommend rewrite
  */
-#define NAND_STATUS_WRITE_RECOMMENDED  BIT(3)
+#define NAND_STATUS_MASK   (BIT(4) | BIT(3) | BIT(0))
+#define NAND_STATUS_NO_ERRORS  0
+#define NAND_STATUS_UNCORRECTABLE  BIT(0)
+#define NAND_STATUS_4_6_CORRECTED  BIT(3)
+#define NAND_STATUS_1_3_CORRECTED  BIT(4)
+#define NAND_STATUS_7_8_CORRECTED  (BIT(4) | BIT(3))
 
 struct nand_onfi_vendor_micron {
u8 two_plane_read;
@@ -137,18 +155,31 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, 
struct nand_chip *chip,
if (ret)
goto out;
 
-   if (status & NAND_STATUS_FAIL) {
+   /*
+* The internal ECC doesn't tell us the number of bitflips
+* that have been corrected, but tells us if it recommends to
+* rewrite the block. If it's the case, then we pretend we had
+* a number of bitflips equal to the ECC strength, which will
+* hint the NAND core to rewrite the block.
+*/
+   switch (status & NAND_STATUS_MASK) {
+   case NAND_STATUS_UNCORRECTABLE:
mtd->ecc_stats.failed++;
-   } else if (status & NAND_STATUS_WRITE_RECOMMENDED) {
-   /*
-* The internal ECC doesn't tell us the number of bitflips
-* that have been corrected, but tells us if it recommends to
-* rewrite the block. If it's the case, then we pretend we had
-* a number of bitflips equal to the ECC strength, which will
-* hint the NAND core to rewrite the block.
-*/
-   mtd->ecc_stats.corrected += chip->ecc.strength;
+   break;
+   case NAND_STATUS_1_3_CORRECTED:
+   mtd->ecc_stats.corrected++;
+   max_bitflips = 1;
+   break;
+   case NAND_STATUS_4_6_CORRECTED:
+   mtd->ecc_stats.corrected += 4;
+   /* rewrite recommended */
+   max_bitflips = chip->ecc.strength;
+   break;
+   case NAND_STATUS_7_8_CORRECTED:
+   mtd->ecc_stats.corrected += 7;
+   /* rewrite recommended */
max_bitflips = chip->ecc.strength;
+   break;
}
 
ret = nand_read_data_op(chip, buf, mtd->writesize, false);
@@ -239,13 +270,6 @@ static int micron_supports_on_die_ecc(struct nand_chip 
*chip)
if (feature[0] & ONFI_FEATURE_ON_DIE_ECC_EN)
return MICRON_ON_DIE_MANDATORY;
 
-   /*
-* Some Micron NANDs have an on-die ECC of 4/512, some other
-* 8/512. We only support the former.
-*/
-   if (chip->ecc_strength_ds != 4)
-   return MICRON_ON_DIE_UNSUPPORTED;
-
return MICRON_ON_DIE_SUPPORTED;
 }
 
@@ -275,9 +299,9 @@ static int micron_nand_init(struct nand_chip *chip)
return -EINVAL;
}
 
-   chip->ecc.bytes = 8;
+   chip->ecc.bytes = chip->ecc_strength_ds * 2;
chip->ecc.size = 512;
-   chip->ecc.strength = 4;
+   chip->ecc.strength = chip->ecc_strength_ds;
chip->ecc.algo = NAND_ECC_BCH;
chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
chip->ecc.write_page = micron_nand_write_page_on_die_ecc;
-- 
2.17.1



[PATCH v5 3/6] mtd: rawnand: add defines for ONFI version bits

2018-06-21 Thread Chris Packham
Add defines for the ONFI version bits and use them in
nand_flash_detect_onfi().

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---

Notes:
Changes in v4:
- New
Changes in v5:
- Add review from Boris

 drivers/mtd/nand/raw/nand_base.c | 10 +-
 include/linux/mtd/rawnand.h  | 11 +++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 65250308c82d..36048e0cf1f5 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5178,15 +5178,15 @@ static int nand_flash_detect_onfi(struct nand_chip 
*chip)
 
/* Check version */
val = le16_to_cpu(p->revision);
-   if (val & (1 << 5))
+   if (val & ONFI_VERSION_2_3)
chip->parameters.onfi.version = 23;
-   else if (val & (1 << 4))
+   else if (val & ONFI_VERSION_2_2)
chip->parameters.onfi.version = 22;
-   else if (val & (1 << 3))
+   else if (val & ONFI_VERSION_2_1)
chip->parameters.onfi.version = 21;
-   else if (val & (1 << 2))
+   else if (val & ONFI_VERSION_2_0)
chip->parameters.onfi.version = 20;
-   else if (val & (1 << 1))
+   else if (val & ONFI_VERSION_1_0)
chip->parameters.onfi.version = 10;
 
if (!chip->parameters.onfi.version) {
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index ef7e3b4e91ea..015bc3f2fc13 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -230,6 +230,17 @@ enum nand_ecc_algo {
 /* Keep gcc happy */
 struct nand_chip;
 
+/* ONFI version bits */
+#define ONFI_VERSION_1_0   BIT(1)
+#define ONFI_VERSION_2_0   BIT(2)
+#define ONFI_VERSION_2_1   BIT(3)
+#define ONFI_VERSION_2_2   BIT(4)
+#define ONFI_VERSION_2_3   BIT(5)
+#define ONFI_VERSION_3_0   BIT(6)
+#define ONFI_VERSION_3_1   BIT(7)
+#define ONFI_VERSION_3_2   BIT(8)
+#define ONFI_VERSION_4_0   BIT(9)
+
 /* ONFI features */
 #define ONFI_FEATURE_16_BIT_BUS(1 << 0)
 #define ONFI_FEATURE_EXT_PARAM_PAGE(1 << 7)
-- 
2.17.1



[PATCH v5 5/6] mtd: rawnand: micron: support 8/512 on-die ECC

2018-06-21 Thread Chris Packham
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
per 512 bytes. Add support for this combination.

Signed-off-by: Chris Packham 
---

Notes:
Changes in v2:
- New
Changes in v3:
- Handle reporting of corrected errors that don't require a rewrite, expand
  comment for the ECC status bits.
Changes in v4:
- Use a switch statement for handling ECC status
- Update ecc_stats.corrected
Changes in v5:
- Move status checking to different routines for 4/512 and 8/512 assume
  the highest number of bit flips for a given status value.

 drivers/mtd/nand/raw/nand_micron.c | 100 +++--
 1 file changed, 79 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index d30bd4df9b12..f83053562925 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -18,10 +18,30 @@
 #include 
 
 /*
- * Special Micron status bit that indicates when the block has been
- * corrected by on-die ECC and should be rewritten
+ * Special Micron status bit 3 indicates that the block has been
+ * corrected by on-die ECC and should be rewritten.
  */
-#define NAND_STATUS_WRITE_RECOMMENDED  BIT(3)
+#define NAND_ECC_STATUS_WRITE_RECOMMENDED  BIT(3)
+
+/*
+ * On chips with 8-bit ECC and additional bit can be used to distinguish
+ * cases where a errors were corrected without needing a rewrite
+ *
+ * Bit 4 Bit 3 Bit 0 Description
+ * - - - ---
+ * 0 0 0 No Errors
+ * 0 0 1 Multiple uncorrected errors
+ * 0 1 0 4 - 6 errors corrected, recommend rewrite
+ * 0 1 1 Reserved
+ * 1 0 0 1 - 3 errors corrected
+ * 1 0 1 Reserved
+ * 1 1 0 7 - 8 errors corrected, recommend rewrite
+ */
+#define NAND_ECC_STATUS_MASK   (BIT(4) | BIT(3) | BIT(0))
+#define NAND_ECC_STATUS_UNCORRECTABLE  BIT(0)
+#define NAND_ECC_STATUS_4_6_CORRECTED  BIT(3)
+#define NAND_ECC_STATUS_1_3_CORRECTED  BIT(4)
+#define NAND_ECC_STATUS_7_8_CORRECTED  (BIT(4) | BIT(3))
 
 struct nand_onfi_vendor_micron {
u8 two_plane_read;
@@ -113,6 +133,54 @@ static int micron_nand_on_die_ecc_setup(struct nand_chip 
*chip, bool enable)
return nand_set_features(chip, ONFI_FEATURE_ON_DIE_ECC, feature);
 }
 
+
+static int micron_nand_on_die_ecc_status_4(struct mtd_info *mtd,
+  struct nand_chip *chip, u8 status)
+{
+   /*
+* The internal ECC doesn't tell us the number of bitflips
+* that have been corrected, but tells us if it recommends to
+* rewrite the block. If it's the case, then we pretend we had
+* a number of bitflips equal to the ECC strength, which will
+* hint the NAND core to rewrite the block.
+*/
+   if (status & NAND_STATUS_FAIL) {
+   mtd->ecc_stats.failed++;
+   } else if (status & NAND_ECC_STATUS_WRITE_RECOMMENDED) {
+   mtd->ecc_stats.corrected += chip->ecc.strength;
+   return chip->ecc.strength;
+   }
+
+   return 0;
+}
+
+static int micron_nand_on_die_ecc_status_8(struct mtd_info *mtd,
+  struct nand_chip *chip, u8 status)
+{
+   /*
+* With 8/512 we have more information but still don't know precisely
+* how many bit-flips were seen.
+*/
+   switch (status & NAND_ECC_STATUS_MASK) {
+   case NAND_ECC_STATUS_UNCORRECTABLE:
+   mtd->ecc_stats.failed++;
+   return 0;
+   case NAND_ECC_STATUS_1_3_CORRECTED:
+   mtd->ecc_stats.corrected += 3;
+   return 3;
+   case NAND_ECC_STATUS_4_6_CORRECTED:
+   mtd->ecc_stats.corrected += 6;
+   /* rewrite recommended */
+   return 6;
+   case NAND_ECC_STATUS_7_8_CORRECTED:
+   mtd->ecc_stats.corrected += 8;
+   /* rewrite recommended */
+   return 8;
+   default:
+   return 0;
+   }
+}
+
 static int
 micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip,
 uint8_t *buf, int oob_required,
@@ -137,19 +205,10 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, 
struct nand_chip *chip,
if (ret)
goto out;
 
-   if (status & NAND_STATUS_FAIL) {
-   mtd->ecc_stats.failed++;
-   } else if (status & NAND_STATUS_WRITE_RECOMMENDED) {
-   /*
-* The internal ECC doesn't tell us the number of bitflips
-* that have been corrected, but tells us if it recommends to
-* rewrite the block. If it's the case, then we pretend we had
-* a number of bitflips equal to the ECC strength, which will
-* hint the NAND core to rewrite th

[PATCH v5 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

2018-06-21 Thread Chris Packham
Hi,

I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.

This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but reports internally as ABAGA. Finally it has internal 8-bit ECC
which cannot be disabled.

The existing test in micron_supports_on_die_ecc() determines that on-die
ECC is supported but not mandatory but I know for this chip it is
mandatory despite what set_features returns.

In order for this to work I need to set nand-ecc-mode = "on-die" in my
dts. Ideally I'd like it to be automatic based on what the hardware can
support but that may be asking too much at the moment.

Here's a dump of the parameter page from the chip I have

: 4f 4e 46 49 00 00 18 00 3f 00 00 00 00 00 00 00 ONFI?...
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0020: 4d 49 43 52 4f 4e 20 20 20 20 20 20 4d 54 32 39  MICRON MT29
0030: 46 31 47 30 38 41 42 41 47 41 57 50 20 20 20 20  F1G08ABAGAWP
0040: 2c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ,...
0050: 00 08 00 00 80 00 00 02 00 00 20 00 40 00 00 00  ..  .@...
0060: 00 04 00 00 01 22 01 14 00 01 05 08 00 00 04 00 ."..
0070: 08 01 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 
0080: 08 3f 00 3f 00 58 02 10 27 46 00 64 00 00 00 00 .?.?.X..'F.d
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00a0: 00 00 00 00 01 00 00 00 00 02 04 80 01 81 04 03 
00b0: 02 01 1e 90 00 00 00 00 00 00 00 00 00 00 00 00 
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 85 a6 

Series changes in v3:
- No longer RFC
- dropped "mtd: rawnand: micron: add ONFI_FEATURE_ON_DIE_ECC to supported
  features" which Boris has already picked up
- dropped "mtd: rawnand: marvell: Support page size of 2048 with 8-bit ECC"
  since I can't test it.

Series changes in v4:
- based on top of http://patchwork.ozlabs.org/patch/932006/

Series changes in v5:
- address review comments from Boris on patches 5 and 6

Chris Packham (6):
  mtd: rawnand: marvell: Handle on-die ECC
  mtd: rawnand: add manufacturer fixup for ONFI parameter page
  mtd: rawnand: add defines for ONFI version bits
  mtd: rawnand: micron: add fixup for ONFI revision
  mtd: rawnand: micron: support 8/512 on-die ECC
  mtd: rawnand: micron: detect forced on-die ECC

 drivers/mtd/nand/raw/marvell_nand.c |   1 +
 drivers/mtd/nand/raw/nand_base.c|  14 +--
 drivers/mtd/nand/raw/nand_micron.c  | 129 +++-
 include/linux/mtd/rawnand.h |  14 +++
 4 files changed, 131 insertions(+), 27 deletions(-)

-- 
2.17.1



[PATCH v5 2/6] mtd: rawnand: add manufacturer fixup for ONFI parameter page

2018-06-21 Thread Chris Packham
This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.

Suggested-by: Boris Brezillon 
Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---

Notes:
Changes in v2:
- New
Changes in v3:
- Add doc comment and review from Boris
Changes in v4:
- None
Changes in v5:
- None

 drivers/mtd/nand/raw/nand_base.c | 4 
 include/linux/mtd/rawnand.h  | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 0cd3e216b95c..65250308c82d 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5172,6 +5172,10 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
}
}
 
+   if (chip->manufacturer.desc && chip->manufacturer.desc->ops &&
+   chip->manufacturer.desc->ops->fixup_onfi_param_page)
+   chip->manufacturer.desc->ops->fixup_onfi_param_page(chip, p);
+
/* Check version */
val = le16_to_cpu(p->revision);
if (val & (1 << 5))
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 3e8ec3b8a39c..ef7e3b4e91ea 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -778,11 +778,14 @@ nand_get_sdr_timings(const struct nand_data_interface 
*conf)
  *   implementation) if any.
  * @cleanup: the ->init() function may have allocated resources, ->cleanup()
  *  is here to let vendor specific code release those resources.
+ * @fixup_onfi_param_page: apply vendor specific fixups to the ONFI
+ * parameter page. This is called after the checksum is verified.
  */
 struct nand_manufacturer_ops {
void (*detect)(struct nand_chip *chip);
int (*init)(struct nand_chip *chip);
void (*cleanup)(struct nand_chip *chip);
+   void (*fixup_onfi_param_page)(struct nand_chip *chip, struct 
nand_onfi_params *p);
 };
 
 /**
-- 
2.17.1



[PATCH v5 4/6] mtd: rawnand: micron: add fixup for ONFI revision

2018-06-21 Thread Chris Packham
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---

Notes:
This is now qualified on vendor == MICRON. I haven't qualified this
based on specific chips the ABAFA (id=d1) and ABBFA (id=a1) variants are
documented to have this behaviour.

Changes in v2:
- use fixup_onfi_param_page
Changes in v3:
- add code comment next to workaround
Changes in v4:
- use define for ONFI_VERSION
Changes in v5:
- None

 drivers/mtd/nand/raw/nand_micron.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index 203faba0a9c1..d30bd4df9b12 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -290,6 +290,19 @@ static int micron_nand_init(struct nand_chip *chip)
return 0;
 }
 
+static void micron_fixup_onfi_param_page(struct nand_chip *chip,
+struct nand_onfi_params *p)
+{
+   /*
+* MT29F1G08ABAFAWP-ITE:F and possibly others report 00 00 for the
+* revision number field of the ONFI parameter page. Assume ONFI
+* version 1.0 if the revision number is 00 00.
+*/
+   if (le16_to_cpu(p->revision) == 0)
+   p->revision = cpu_to_le16(ONFI_VERSION_1_0);
+}
+
 const struct nand_manufacturer_ops micron_nand_manuf_ops = {
.init = micron_nand_init,
+   .fixup_onfi_param_page = micron_fixup_onfi_param_page,
 };
-- 
2.17.1



[PATCH v5 6/6] mtd: rawnand: micron: detect forced on-die ECC

2018-06-21 Thread Chris Packham
Some Micron NAND chips have on-die ECC forceably enabled. The detect
these based on chip ID as there seems to be no other way of
distinguishing these chips from those that have optional support for
on-die ECC.

When a chip with mandatory on-die ECC is detected change the current ECC
mode to on-die.

Signed-off-by: Chris Packham 
---

Notes:
Changes in v4:
- New
Changes in v5:
- fail if on-die ECC is mandatory and the current ecc.mode is not
  NAND_ECC_ON_DIE.

 drivers/mtd/nand/raw/nand_micron.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index f83053562925..35fa6880a799 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -255,6 +255,14 @@ enum {
MICRON_ON_DIE_MANDATORY,
 };
 
+/*
+ * These parts are known to have on-die ECC forceably enabled
+ */
+static u8 micron_on_die_ecc[] = {
+   0xd1, /* MT29F1G08ABAFA */
+   0xa1, /* MT29F1G08ABBFA */
+};
+
 /*
  * Try to detect if the NAND support on-die ECC. To do this, we enable
  * the feature, and read back if it has been enabled as expected. We
@@ -269,6 +277,11 @@ static int micron_supports_on_die_ecc(struct nand_chip 
*chip)
 {
u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = { 0, };
int ret;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(micron_on_die_ecc); i++)
+   if (chip->id.data[1] == micron_on_die_ecc[i])
+   return MICRON_ON_DIE_MANDATORY;
 
if (!chip->parameters.onfi.version)
return MICRON_ON_DIE_UNSUPPORTED;
@@ -322,7 +335,8 @@ static int micron_nand_init(struct nand_chip *chip)
 
ondie = micron_supports_on_die_ecc(chip);
 
-   if (ondie == MICRON_ON_DIE_MANDATORY) {
+   if (ondie == MICRON_ON_DIE_MANDATORY &&
+   chip->ecc.mode != NAND_ECC_ON_DIE) {
pr_err("On-die ECC forcefully enabled, not supported\n");
return -EINVAL;
}
-- 
2.17.1



[PATCH v5 1/6] mtd: rawnand: marvell: Handle on-die ECC

2018-06-21 Thread Chris Packham
>From the controllers point of view this is the same as no or
software only ECC.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---

Notes:
Changes in v2:
- New
Changes in v3:
- Add review from Boris
Changes in v4:
- None
Changes in v5:
- None

 drivers/mtd/nand/raw/marvell_nand.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/marvell_nand.c 
b/drivers/mtd/nand/raw/marvell_nand.c
index ebb1d141b900..ba6889bbe802 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -2157,6 +2157,7 @@ static int marvell_nand_ecc_init(struct mtd_info *mtd,
break;
case NAND_ECC_NONE:
case NAND_ECC_SOFT:
+   case NAND_ECC_ON_DIE:
if (!nfc->caps->is_nfcv2 && mtd->writesize != SZ_512 &&
mtd->writesize != SZ_2K) {
dev_err(nfc->dev, "NFCv1 cannot write %d bytes pages\n",
-- 
2.17.1



[PATCH v6 5/6] mtd: rawnand: micron: support 8/512 on-die ECC

2018-06-24 Thread Chris Packham
Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
per 512 bytes. Add support for this combination.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
Changes in v2:
- New
Changes in v3:
- Handle reporting of corrected errors that don't require a rewrite, expand
  comment for the ECC status bits.
Changes in v4:
- Use a switch statement for handling ECC status
- Update ecc_stats.corrected
Changes in v5:
- Move status checking to different routines for 4/512 and 8/512 assume
  the highest number of bit flips for a given status value.
Changes in v6:
- Add review from Boris

 drivers/mtd/nand/raw/nand_micron.c | 100 +++--
 1 file changed, 79 insertions(+), 21 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index d30bd4df9b12..f83053562925 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -18,10 +18,30 @@
 #include 
 
 /*
- * Special Micron status bit that indicates when the block has been
- * corrected by on-die ECC and should be rewritten
+ * Special Micron status bit 3 indicates that the block has been
+ * corrected by on-die ECC and should be rewritten.
  */
-#define NAND_STATUS_WRITE_RECOMMENDED  BIT(3)
+#define NAND_ECC_STATUS_WRITE_RECOMMENDED  BIT(3)
+
+/*
+ * On chips with 8-bit ECC and additional bit can be used to distinguish
+ * cases where a errors were corrected without needing a rewrite
+ *
+ * Bit 4 Bit 3 Bit 0 Description
+ * - - - ---
+ * 0 0 0 No Errors
+ * 0 0 1 Multiple uncorrected errors
+ * 0 1 0 4 - 6 errors corrected, recommend rewrite
+ * 0 1 1 Reserved
+ * 1 0 0 1 - 3 errors corrected
+ * 1 0 1 Reserved
+ * 1 1 0 7 - 8 errors corrected, recommend rewrite
+ */
+#define NAND_ECC_STATUS_MASK   (BIT(4) | BIT(3) | BIT(0))
+#define NAND_ECC_STATUS_UNCORRECTABLE  BIT(0)
+#define NAND_ECC_STATUS_4_6_CORRECTED  BIT(3)
+#define NAND_ECC_STATUS_1_3_CORRECTED  BIT(4)
+#define NAND_ECC_STATUS_7_8_CORRECTED  (BIT(4) | BIT(3))
 
 struct nand_onfi_vendor_micron {
u8 two_plane_read;
@@ -113,6 +133,54 @@ static int micron_nand_on_die_ecc_setup(struct nand_chip 
*chip, bool enable)
return nand_set_features(chip, ONFI_FEATURE_ON_DIE_ECC, feature);
 }
 
+
+static int micron_nand_on_die_ecc_status_4(struct mtd_info *mtd,
+  struct nand_chip *chip, u8 status)
+{
+   /*
+* The internal ECC doesn't tell us the number of bitflips
+* that have been corrected, but tells us if it recommends to
+* rewrite the block. If it's the case, then we pretend we had
+* a number of bitflips equal to the ECC strength, which will
+* hint the NAND core to rewrite the block.
+*/
+   if (status & NAND_STATUS_FAIL) {
+   mtd->ecc_stats.failed++;
+   } else if (status & NAND_ECC_STATUS_WRITE_RECOMMENDED) {
+   mtd->ecc_stats.corrected += chip->ecc.strength;
+   return chip->ecc.strength;
+   }
+
+   return 0;
+}
+
+static int micron_nand_on_die_ecc_status_8(struct mtd_info *mtd,
+  struct nand_chip *chip, u8 status)
+{
+   /*
+* With 8/512 we have more information but still don't know precisely
+* how many bit-flips were seen.
+*/
+   switch (status & NAND_ECC_STATUS_MASK) {
+   case NAND_ECC_STATUS_UNCORRECTABLE:
+   mtd->ecc_stats.failed++;
+   return 0;
+   case NAND_ECC_STATUS_1_3_CORRECTED:
+   mtd->ecc_stats.corrected += 3;
+   return 3;
+   case NAND_ECC_STATUS_4_6_CORRECTED:
+   mtd->ecc_stats.corrected += 6;
+   /* rewrite recommended */
+   return 6;
+   case NAND_ECC_STATUS_7_8_CORRECTED:
+   mtd->ecc_stats.corrected += 8;
+   /* rewrite recommended */
+   return 8;
+   default:
+   return 0;
+   }
+}
+
 static int
 micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip,
 uint8_t *buf, int oob_required,
@@ -137,19 +205,10 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, 
struct nand_chip *chip,
if (ret)
goto out;
 
-   if (status & NAND_STATUS_FAIL) {
-   mtd->ecc_stats.failed++;
-   } else if (status & NAND_STATUS_WRITE_RECOMMENDED) {
-   /*
-* The internal ECC doesn't tell us the number of bitflips
-* that have been corrected, but tells us if it recommends to
-* rewrite the block. If it's the case, then we pretend we had
-* a number of bitflips equal to the ECC strength, which will
-* hint the NAND core to re

[PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

2018-06-24 Thread Chris Packham
Hi,

I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.

This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but reports internally as ABAGA. Finally it has internal 8-bit ECC
which cannot be disabled.

The existing test in micron_supports_on_die_ecc() determines that on-die
ECC is supported but not mandatory but I know for this chip it is
mandatory despite what set_features returns.

In order for this to work I need to set nand-ecc-mode = "on-die" in my
dts. Ideally I'd like it to be automatic based on what the hardware can
support but that may be asking too much at the moment.

Here's a dump of the parameter page from the chip I have

: 4f 4e 46 49 00 00 18 00 3f 00 00 00 00 00 00 00 ONFI?...
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0020: 4d 49 43 52 4f 4e 20 20 20 20 20 20 4d 54 32 39  MICRON MT29
0030: 46 31 47 30 38 41 42 41 47 41 57 50 20 20 20 20  F1G08ABAGAWP
0040: 2c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ,...
0050: 00 08 00 00 80 00 00 02 00 00 20 00 40 00 00 00  ..  .@...
0060: 00 04 00 00 01 22 01 14 00 01 05 08 00 00 04 00 ."..
0070: 08 01 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 
0080: 08 3f 00 3f 00 58 02 10 27 46 00 64 00 00 00 00 .?.?.X..'F.d
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00a0: 00 00 00 00 01 00 00 00 00 02 04 80 01 81 04 03 
00b0: 02 01 1e 90 00 00 00 00 00 00 00 00 00 00 00 00 
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 85 a6 

Series changes in v3:
- No longer RFC
- dropped "mtd: rawnand: micron: add ONFI_FEATURE_ON_DIE_ECC to supported
  features" which Boris has already picked up
- dropped "mtd: rawnand: marvell: Support page size of 2048 with 8-bit ECC"
  since I can't test it.

Series changes in v4:
- based on top of http://patchwork.ozlabs.org/patch/932006/

Series changes in v5:
- address review comments from Boris on patches 5 and 6

Series changes in v6:
- Update commit message on 6/6

Chris Packham (6):
  mtd: rawnand: marvell: Handle on-die ECC
  mtd: rawnand: add manufacturer fixup for ONFI parameter page
  mtd: rawnand: add defines for ONFI version bits
  mtd: rawnand: micron: add fixup for ONFI revision
  mtd: rawnand: micron: support 8/512 on-die ECC
  mtd: rawnand: micron: detect forced on-die ECC

 drivers/mtd/nand/raw/marvell_nand.c |   1 +
 drivers/mtd/nand/raw/nand_base.c|  14 +--
 drivers/mtd/nand/raw/nand_micron.c  | 129 +++-
 include/linux/mtd/rawnand.h |  14 +++
 4 files changed, 131 insertions(+), 27 deletions(-)

-- 
2.18.0



[PATCH v6 1/6] mtd: rawnand: marvell: Handle on-die ECC

2018-06-24 Thread Chris Packham
>From the controllers point of view this is the same as no or
software only ECC.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
Changes in v2:
- New
Changes in v3:
- Add review from Boris
Changes in v4:
- None
Changes in v5:
- None
Changes in v6:
- None

 drivers/mtd/nand/raw/marvell_nand.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/marvell_nand.c 
b/drivers/mtd/nand/raw/marvell_nand.c
index ebb1d141b900..ba6889bbe802 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -2157,6 +2157,7 @@ static int marvell_nand_ecc_init(struct mtd_info *mtd,
break;
case NAND_ECC_NONE:
case NAND_ECC_SOFT:
+   case NAND_ECC_ON_DIE:
if (!nfc->caps->is_nfcv2 && mtd->writesize != SZ_512 &&
mtd->writesize != SZ_2K) {
dev_err(nfc->dev, "NFCv1 cannot write %d bytes pages\n",
-- 
2.18.0



[PATCH v6 4/6] mtd: rawnand: micron: add fixup for ONFI revision

2018-06-24 Thread Chris Packham
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
This is now qualified on vendor == MICRON. I haven't qualified this
based on specific chips the ABAFA (id=d1) and ABBFA (id=a1) variants are
documented to have this behaviour.

Changes in v2:
- use fixup_onfi_param_page
Changes in v3:
- add code comment next to workaround
Changes in v4:
- use define for ONFI_VERSION
Changes in v5:
- None
Changes in v6:
- None

 drivers/mtd/nand/raw/nand_micron.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index 203faba0a9c1..d30bd4df9b12 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -290,6 +290,19 @@ static int micron_nand_init(struct nand_chip *chip)
return 0;
 }
 
+static void micron_fixup_onfi_param_page(struct nand_chip *chip,
+struct nand_onfi_params *p)
+{
+   /*
+* MT29F1G08ABAFAWP-ITE:F and possibly others report 00 00 for the
+* revision number field of the ONFI parameter page. Assume ONFI
+* version 1.0 if the revision number is 00 00.
+*/
+   if (le16_to_cpu(p->revision) == 0)
+   p->revision = cpu_to_le16(ONFI_VERSION_1_0);
+}
+
 const struct nand_manufacturer_ops micron_nand_manuf_ops = {
.init = micron_nand_init,
+   .fixup_onfi_param_page = micron_fixup_onfi_param_page,
 };
-- 
2.18.0



[PATCH v6 2/6] mtd: rawnand: add manufacturer fixup for ONFI parameter page

2018-06-24 Thread Chris Packham
This is called after the ONFI parameter page checksum is verified
and allows us to override the contents of the parameter page.

Suggested-by: Boris Brezillon 
Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
Changes in v2:
- New
Changes in v3:
- Add doc comment and review from Boris
Changes in v4:
- None
Changes in v5:
- None
Changes in v6:
- None

 drivers/mtd/nand/raw/nand_base.c | 4 
 include/linux/mtd/rawnand.h  | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 0cd3e216b95c..65250308c82d 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5172,6 +5172,10 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
}
}
 
+   if (chip->manufacturer.desc && chip->manufacturer.desc->ops &&
+   chip->manufacturer.desc->ops->fixup_onfi_param_page)
+   chip->manufacturer.desc->ops->fixup_onfi_param_page(chip, p);
+
/* Check version */
val = le16_to_cpu(p->revision);
if (val & (1 << 5))
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 3e8ec3b8a39c..ef7e3b4e91ea 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -778,11 +778,14 @@ nand_get_sdr_timings(const struct nand_data_interface 
*conf)
  *   implementation) if any.
  * @cleanup: the ->init() function may have allocated resources, ->cleanup()
  *  is here to let vendor specific code release those resources.
+ * @fixup_onfi_param_page: apply vendor specific fixups to the ONFI
+ * parameter page. This is called after the checksum is verified.
  */
 struct nand_manufacturer_ops {
void (*detect)(struct nand_chip *chip);
int (*init)(struct nand_chip *chip);
void (*cleanup)(struct nand_chip *chip);
+   void (*fixup_onfi_param_page)(struct nand_chip *chip, struct 
nand_onfi_params *p);
 };
 
 /**
-- 
2.18.0



[PATCH v6 6/6] mtd: rawnand: micron: detect forced on-die ECC

2018-06-24 Thread Chris Packham
Some Micron NAND chips have on-die ECC forceably enabled. Detect these
based on chip ID as there seems to be no other way of distinguishing
these chips from those that have optional support for on-die ECC.

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
Changes in v4:
- New
Changes in v5:
- fail if on-die ECC is mandatory and the current ecc.mode is not
  NAND_ECC_ON_DIE.
Changes in v6:
- Update commit message, add review from Boris

 drivers/mtd/nand/raw/nand_micron.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/raw/nand_micron.c 
b/drivers/mtd/nand/raw/nand_micron.c
index f83053562925..35fa6880a799 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -255,6 +255,14 @@ enum {
MICRON_ON_DIE_MANDATORY,
 };
 
+/*
+ * These parts are known to have on-die ECC forceably enabled
+ */
+static u8 micron_on_die_ecc[] = {
+   0xd1, /* MT29F1G08ABAFA */
+   0xa1, /* MT29F1G08ABBFA */
+};
+
 /*
  * Try to detect if the NAND support on-die ECC. To do this, we enable
  * the feature, and read back if it has been enabled as expected. We
@@ -269,6 +277,11 @@ static int micron_supports_on_die_ecc(struct nand_chip 
*chip)
 {
u8 feature[ONFI_SUBFEATURE_PARAM_LEN] = { 0, };
int ret;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(micron_on_die_ecc); i++)
+   if (chip->id.data[1] == micron_on_die_ecc[i])
+   return MICRON_ON_DIE_MANDATORY;
 
if (!chip->parameters.onfi.version)
return MICRON_ON_DIE_UNSUPPORTED;
@@ -322,7 +335,8 @@ static int micron_nand_init(struct nand_chip *chip)
 
ondie = micron_supports_on_die_ecc(chip);
 
-   if (ondie == MICRON_ON_DIE_MANDATORY) {
+   if (ondie == MICRON_ON_DIE_MANDATORY &&
+   chip->ecc.mode != NAND_ECC_ON_DIE) {
pr_err("On-die ECC forcefully enabled, not supported\n");
return -EINVAL;
}
-- 
2.18.0



[PATCH v6 3/6] mtd: rawnand: add defines for ONFI version bits

2018-06-24 Thread Chris Packham
Add defines for the ONFI version bits and use them in
nand_flash_detect_onfi().

Signed-off-by: Chris Packham 
Reviewed-by: Boris Brezillon 
---
Changes in v4:
- New
Changes in v5:
- Add review from Boris
Changes in v6:
- None

 drivers/mtd/nand/raw/nand_base.c | 10 +-
 include/linux/mtd/rawnand.h  | 11 +++
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 65250308c82d..36048e0cf1f5 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5178,15 +5178,15 @@ static int nand_flash_detect_onfi(struct nand_chip 
*chip)
 
/* Check version */
val = le16_to_cpu(p->revision);
-   if (val & (1 << 5))
+   if (val & ONFI_VERSION_2_3)
chip->parameters.onfi.version = 23;
-   else if (val & (1 << 4))
+   else if (val & ONFI_VERSION_2_2)
chip->parameters.onfi.version = 22;
-   else if (val & (1 << 3))
+   else if (val & ONFI_VERSION_2_1)
chip->parameters.onfi.version = 21;
-   else if (val & (1 << 2))
+   else if (val & ONFI_VERSION_2_0)
chip->parameters.onfi.version = 20;
-   else if (val & (1 << 1))
+   else if (val & ONFI_VERSION_1_0)
chip->parameters.onfi.version = 10;
 
if (!chip->parameters.onfi.version) {
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index ef7e3b4e91ea..015bc3f2fc13 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -230,6 +230,17 @@ enum nand_ecc_algo {
 /* Keep gcc happy */
 struct nand_chip;
 
+/* ONFI version bits */
+#define ONFI_VERSION_1_0   BIT(1)
+#define ONFI_VERSION_2_0   BIT(2)
+#define ONFI_VERSION_2_1   BIT(3)
+#define ONFI_VERSION_2_2   BIT(4)
+#define ONFI_VERSION_2_3   BIT(5)
+#define ONFI_VERSION_3_0   BIT(6)
+#define ONFI_VERSION_3_1   BIT(7)
+#define ONFI_VERSION_3_2   BIT(8)
+#define ONFI_VERSION_4_0   BIT(9)
+
 /* ONFI features */
 #define ONFI_FEATURE_16_BIT_BUS(1 << 0)
 #define ONFI_FEATURE_EXT_PARAM_PAGE(1 << 7)
-- 
2.18.0



[PATCH v5] ARM: mvebu: use dt_fixup to provide fallback for enable-method

2018-07-25 Thread Chris Packham
We need to maintain backwards compatibility with device trees that don't
define an enable method. At the same time we want the device tree to be
able to specify an enable-method and have it stick.

Previously by having smp assigned in the DT_MACHINE definition this
would be picked up by setup_arch() and override whatever
arm_dt_init_cpu_maps() had configured. Now we move the initial
assignment of default smp_ops to a dt_fixup and let
arm_dt_init_cpu_maps() override that if the device tree defines an
enable-method.

Signed-off-by: Chris Packham 
---
Pervious versions

v1: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/300182.html
v2: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/300480.html
v3: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302945.html
v4: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/303899.html

Changes since v4:
- drop "RFC"

 arch/arm/mach-mvebu/board-v7.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index ccca95173e17..5bbde5e5258e 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -145,6 +145,11 @@ static void __init mvebu_dt_init(void)
i2c_quirk();
 }
 
+static void __init armada_370_xp_dt_fixup(void)
+{
+   smp_set_ops(smp_ops(armada_xp_smp_ops));
+}
+
 static const char * const armada_370_xp_dt_compat[] __initconst = {
"marvell,armada-370-xp",
NULL,
@@ -153,17 +158,12 @@ static const char * const armada_370_xp_dt_compat[] 
__initconst = {
 DT_MACHINE_START(ARMADA_370_XP_DT, "Marvell Armada 370/XP (Device Tree)")
.l2c_aux_val= 0,
.l2c_aux_mask   = ~0,
-/*
- * The following field (.smp) is still needed to ensure backward
- * compatibility with old Device Trees that were not specifying the
- * cpus enable-method property.
- */
-   .smp= smp_ops(armada_xp_smp_ops),
.init_machine   = mvebu_dt_init,
.init_irq   = mvebu_init_irq,
.restart= mvebu_restart,
.reserve= mvebu_memblock_reserve,
.dt_compat  = armada_370_xp_dt_compat,
+   .dt_fixup   = armada_370_xp_dt_fixup,
 MACHINE_END
 
 static const char * const armada_375_dt_compat[] __initconst = {
-- 
2.18.0



[PATCH 2/4] ARM: dts: mvebu: db-dxbc2: use new style nand binding

2018-07-25 Thread Chris Packham
Update the nand flash binding to the new style.

Signed-off-by: Chris Packham 
---
 arch/arm/boot/dts/armada-xp-db-dxbc2.dts | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts 
b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
index 944e0a9c9dac..8a3aa616bbd0 100644
--- a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
+++ b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
@@ -70,12 +70,16 @@
 
 &nand_controller {
status = "okay";
-   label = "pxa3xx_nand-0";
-   num-cs = <1>;
-   marvell,nand-keep-config;
-   nand-on-flash-bbt;
-   nand-ecc-strength = <4>;
-   nand-ecc-step-size = <512>;
+
+   nand@0 {
+   reg = <0>;
+   label = "pxa3xx_nand-0";
+   nand-rb = <0>;
+   marvell,nand-keep-config;
+   nand-on-flash-bbt;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   };
 };
 
 &sdio {
-- 
2.18.0



[PATCH 3/4] ARM: dts: mvebu: db-xc3-24g4: use new style nand binding

2018-07-25 Thread Chris Packham
Update the nand flash binding to the new style.

Signed-off-by: Chris Packham 
---
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts 
b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
index d58ea48cb151..df048050615f 100644
--- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
+++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
@@ -69,12 +69,16 @@
 
 &nand_controller {
status = "okay";
-   label = "pxa3xx_nand-0";
-   num-cs = <1>;
-   marvell,nand-keep-config;
-   nand-on-flash-bbt;
-   nand-ecc-strength = <4>;
-   nand-ecc-step-size = <512>;
+
+   nand@0 {
+   reg = <0>;
+   label = "pxa3xx_nand-0";
+   nand-rb = <0>;
+   marvell,nand-keep-config;
+   nand-on-flash-bbt;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   };
 };
 
 &spi0 {
-- 
2.18.0



[PATCH 4/4] ARM: dts: mvebu: Add device tree for db-88f6820-amc board

2018-07-25 Thread Chris Packham
This board is a plugin card for some of Marvell's switch development
kits. It's similar to the non-amc board except that it has no SATA
support.

Signed-off-by: Chris Packham 
---
 arch/arm/boot/dts/Makefile|   1 +
 .../boot/dts/armada-385-db-88f6820-amc.dts| 147 ++
 2 files changed, 148 insertions(+)
 create mode 100644 arch/arm/boot/dts/armada-385-db-88f6820-amc.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 37a3de760d40..e4212b7b7d9e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1126,6 +1126,7 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
 dtb-$(CONFIG_MACH_ARMADA_375) += \
armada-375-db.dtb
 dtb-$(CONFIG_MACH_ARMADA_38X) += \
+   armada-385-db-88f6820-amc.dtb \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
diff --git a/arch/arm/boot/dts/armada-385-db-88f6820-amc.dts 
b/arch/arm/boot/dts/armada-385-db-88f6820-amc.dts
new file mode 100644
index ..d87614057e3f
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-db-88f6820-amc.dts
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Marvell Armada 385 AMC board
+ * (DB-88F6820-AMC)
+ *
+ * Copyright (C) 2017 Allied Telesis Labs
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+
+#include 
+
+/ {
+   model = "Marvell Armada 385 AMC";
+   compatible = "marvell,a385-db-amc", "marvell,armada385", 
"marvell,armada380";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   ethernet0 = ð0;
+   ethernet1 = ð1;
+   spi1 = &spi1;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x8000>; /* 2GB */
+   };
+
+   soc {
+   ranges = ;
+   };
+};
+
+&i2c0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c0_pins>;
+   status = "okay";
+};
+
+&uart0 {
+   /*
+* Exported on the micro USB connector CON3
+* through an FTDI
+*/
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart0_pins>;
+   status = "okay";
+};
+
+
+ð0 {
+   pinctrl-names = "default";
+   /*
+* The Reference Clock 0 is used to provide a
+* clock to the PHY
+*/
+   pinctrl-0 = <&ge0_rgmii_pins>, <&ref_clk0_pins>;
+   status = "okay";
+   phy = <&phy0>;
+   phy-mode = "rgmii-id";
+};
+
+ð2 {
+   status = "okay";
+   phy = <&phy1>;
+   phy-mode = "sgmii";
+};
+
+&usb0 {
+   status = "okay";
+};
+
+
+
+&mdio {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mdio_pins>;
+
+   phy0: ethernet-phy@1 {
+   reg = <1>;
+   };
+
+   phy1: ethernet-phy@0 {
+   reg = <0>;
+   };
+};
+
+&nand_controller {
+   status = "okay";
+
+   nand@0 {
+   reg = <0>;
+   label = "pxa3xx_nand-0";
+   nand-rb = <0>;
+   nand-on-flash-bbt;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+
+   partition@user {
+   reg = <0x 0x4000>;
+   label = "user";
+   };
+   };
+};
+
+&pciec {
+   status = "okay";
+};
+
+&pcie1 {
+   /* Port 0, Lane 0 */
+   status = "okay";
+};
+
+&spi1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&spi1_pins>;
+   status = "okay";
+
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "jedec,spi-nor";
+   reg = <0>; /* Chip select 0 */
+   spi-max-frequency = <5000>;
+   m25p,fast-read;
+
+   partition@u-boot {
+   reg = <0x 0x0010>;
+   label = "u-boot";
+   };
+   partition@u-boot-env {
+   reg = <0x0010 0x0004>;
+   label = "u-boot-env";
+   };
+   };
+};
+
+&refclk {
+   clock-frequency = <2000>;
+};
-- 
2.18.0



[PATCH 0/4] ARM: dts: mvebu: updates and new board

2018-07-25 Thread Chris Packham
This series updates the armada-xp-98dx3236 SoC and related boards to use the
new style dts bindings for nand.

I've also added a new db-88f6820-amc board which is an Armada-385 based
reference board from Marvell's switch team. It's a plugin card for either the
db-dxbc2 or db-xc3-24g4 which can be used if you disable the internal CPU on
those platforms.

Chris Packham (4):
  ARM: dts: mvebu: 98dx3236: Rename nand controller node
  ARM: dts: mvebu: db-dxbc2: use new style nand binding
  ARM: dts: mvebu: db-xc3-24g4: use new style nand binding
  ARM: dts: mvebu: Add device tree for db-88f6820-amc board

 arch/arm/boot/dts/Makefile|   1 +
 .../boot/dts/armada-385-db-88f6820-amc.dts| 184 ++
 arch/arm/boot/dts/armada-xp-98dx3236.dtsi |   2 +-
 arch/arm/boot/dts/armada-xp-db-dxbc2.dts  |  18 +-
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts |  18 +-
 5 files changed, 208 insertions(+), 15 deletions(-)
 create mode 100644 arch/arm/boot/dts/armada-385-db-88f6820-amc.dts

-- 
2.18.0



[PATCH 1/4] ARM: dts: mvebu: 98dx3236: Rename nand controller node

2018-07-25 Thread Chris Packham
Update the 98dx3236 SoC and dependent boards to use
"nand-controller" instead of "nand".

Signed-off-by: Chris Packham 
---
 arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
 arch/arm/boot/dts/armada-xp-db-dxbc2.dts  | 2 +-
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi 
b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index 8d708cc22495..eb03a5773903 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -189,7 +189,7 @@
};
};
 
-   nand: nand@d {
+   nand_controller: nand-controller@d {
clocks = <&dfx_coredivclk 0>;
};
 
diff --git a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts 
b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
index f42fc6118b7c..944e0a9c9dac 100644
--- a/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
+++ b/arch/arm/boot/dts/armada-xp-db-dxbc2.dts
@@ -68,7 +68,7 @@
status = "okay";
 };
 
-&nand {
+&nand_controller {
status = "okay";
label = "pxa3xx_nand-0";
num-cs = <1>;
diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts 
b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
index 8432f517e346..d58ea48cb151 100644
--- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
+++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
@@ -67,7 +67,7 @@
status = "okay";
 };
 
-&nand {
+&nand_controller {
status = "okay";
label = "pxa3xx_nand-0";
num-cs = <1>;
-- 
2.18.0



[PATCH] arm_pmu: fix compiler warning in arm_pmu_device_probe

2018-08-01 Thread Chris Packham
GCC warns

  arm_pmu_platform.c:234:5: error: 'err' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

This is because we rely on the for_each_cpu loop in armpmu_request_irqs
to initialise err. The warning is a little bogus because we know if
there were 0 CPUs this code would not be running.

Initialise err to 0 to avoid the warning.

Signed-off-by: Chris Packham 
---
This has been reported before in https://lkml.org/lkml/2018/3/5/508 I'm not
sure if it was dismmissed as "meh, gcc is wrong" or if it was just wainting for
someone with some round tuits.


 drivers/perf/arm_pmu_platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/perf/arm_pmu_platform.c b/drivers/perf/arm_pmu_platform.c
index 971ff336494a..96075cecb0ae 100644
--- a/drivers/perf/arm_pmu_platform.c
+++ b/drivers/perf/arm_pmu_platform.c
@@ -160,7 +160,7 @@ static int pmu_parse_irqs(struct arm_pmu *pmu)
 static int armpmu_request_irqs(struct arm_pmu *armpmu)
 {
struct pmu_hw_events __percpu *hw_events = armpmu->hw_events;
-   int cpu, err;
+   int cpu, err = 0;
 
for_each_cpu(cpu, &armpmu->supported_cpus) {
int irq = per_cpu(hw_events->irq, cpu);
-- 
2.18.0



Re: [PATCH v3 4/4] hwmon: (adt7475) add high frequency support

2017-05-11 Thread Chris Packham
On 11/05/17 15:45, Chris Packham wrote:
> Systems using 4-wire fans usually require high frequency (22.5kHz)
> output on the pwm. Add 22500 as a valid option in the pwmfreq_table. In
> high frequency mode the low-order bit are ignored so they can safely be
> set to 0.
>
> Signed-off-by: Chris Packham 
> ---
> Changes in v3:
> - New
>
>  drivers/hwmon/adt7475.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
> index f7322330789c..f5a65d1166cd 100644
> --- a/drivers/hwmon/adt7475.c
> +++ b/drivers/hwmon/adt7475.c
> @@ -936,7 +936,7 @@ static ssize_t set_pwmctrl(struct device *dev, struct 
> device_attribute *attr,
>
>  /* List of frequencies for the PWM */
>  static const int pwmfreq_table[] = {
> - 11, 14, 22, 29, 35, 44, 58, 88
> + 11, 14, 22, 29, 35, 44, 58, 88, 22500
>  };
>
>  static ssize_t show_pwmfreq(struct device *dev, struct device_attribute 
> *attr,
> @@ -944,9 +944,10 @@ static ssize_t show_pwmfreq(struct device *dev, struct 
> device_attribute *attr,
>  {
>   struct adt7475_data *data = adt7475_update_device(dev);
>   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
> + int i = clamp_val(data->range[sattr->index] & 0xf, 0,
> +   sizeof(pwmfreq_table));

Oops that should probably be

+ ARRAY_SIZE(pwmfreq_table) - 1);

Guenter, do you want me to send a v4 or can you fix it up at your end?

>
> - return sprintf(buf, "%d\n",
> -pwmfreq_table[data->range[sattr->index] & 7]);
> + return sprintf(buf, "%d\n", pwmfreq_table[i]);
>  }
>
>  static ssize_t set_pwmfreq(struct device *dev, struct device_attribute *attr,
> @@ -967,7 +968,7 @@ static ssize_t set_pwmfreq(struct device *dev, struct 
> device_attribute *attr,
>
>   data->range[sattr->index] =
>   adt7475_read(TEMP_TRANGE_REG(sattr->index));
> - data->range[sattr->index] &= ~7;
> + data->range[sattr->index] &= ~0xf;
>   data->range[sattr->index] |= out;
>
>   i2c_smbus_write_byte_data(client, TEMP_TRANGE_REG(sattr->index),
>



[PATCH 3/3] EDAC: mv64x60: replace in_le32/out_le32 with ioread32/iowrite32

2017-05-11 Thread Chris Packham
To allow this driver to be used on non-powerpc platforms it needs to use
io accessors suitable for all platforms.

Signed-off-by: Chris Packham 
---
 drivers/edac/mv64x60_edac.c | 84 ++---
 1 file changed, 42 insertions(+), 42 deletions(-)

diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index ddc5082f7577..102ec29f864b 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -32,21 +32,21 @@ static void mv64x60_pci_check(struct edac_pci_ctl_info *pci)
struct mv64x60_pci_pdata *pdata = pci->pvt_info;
u32 cause;
 
-   cause = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+   cause = ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
if (!cause)
return;
 
printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
printk(KERN_ERR "Cause register: 0x%08x\n", cause);
printk(KERN_ERR "Address Low: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
+  ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
printk(KERN_ERR "Address High: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
+  ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
printk(KERN_ERR "Attribute: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
+  ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
printk(KERN_ERR "Command: 0x%08x\n",
-  in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, ~cause);
+  ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
+   iowrite32(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
 
if (cause & MV64X60_PCI_PE_MASK)
edac_pci_handle_pe(pci, pci->ctl_name);
@@ -61,7 +61,7 @@ static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
struct mv64x60_pci_pdata *pdata = pci->pvt_info;
u32 val;
 
-   val = in_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+   val = ioread32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
if (!val)
return IRQ_NONE;
 
@@ -93,7 +93,7 @@ static int __init mv64x60_pci_fixup(struct platform_device 
*pdev)
if (!pci_serr)
return -ENOMEM;
 
-   out_le32(pci_serr, in_le32(pci_serr) & ~0x1);
+   iowrite32(ioread32(pci_serr) & ~0x1, pci_serr);
iounmap(pci_serr);
 
return 0;
@@ -161,10 +161,10 @@ static int mv64x60_pci_err_probe(struct platform_device 
*pdev)
goto err;
}
 
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE, 0);
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK, 0);
-   out_le32(pdata->pci_vbase + MV64X60_PCI_ERROR_MASK,
-MV64X60_PCIx_ERR_MASK_VAL);
+   iowrite32(0, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
+   iowrite32(0, pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
+   iowrite32(MV64X60_PCIx_ERR_MASK_VAL,
+ pdata->pci_vbase + MV64X60_PCI_ERROR_MASK);
 
if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
edac_dbg(3, "failed edac_pci_add_device()\n");
@@ -233,23 +233,23 @@ static void mv64x60_sram_check(struct 
edac_device_ctl_info *edac_dev)
struct mv64x60_sram_pdata *pdata = edac_dev->pvt_info;
u32 cause;
 
-   cause = in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
+   cause = ioread32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE);
if (!cause)
return;
 
printk(KERN_ERR "Error in internal SRAM\n");
printk(KERN_ERR "Cause register: 0x%08x\n", cause);
printk(KERN_ERR "Address Low: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
+  ioread32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_LO));
printk(KERN_ERR "Address High: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_HI));
+  ioread32(pdata->sram_vbase + MV64X60_SRAM_ERR_ADDR_HI));
printk(KERN_ERR "Data Low: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_LO));
+  ioread32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_LO));
printk(KERN_ERR "Data High: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_HI));
+  ioread32(pdata->sram_vbase + MV64X60_SRAM_ERR_DATA_HI));
printk(KERN_ERR "Parity: 0x%08x\n",
-  in_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_PARITY));
-   out_le32(pdata->sram_vbase + MV64X60_SRAM_ERR_CAUSE, 0);
+  io

[PATCH 1/3] EDAC: mv64x60: remove unused variable

2017-05-11 Thread Chris Packham
Signed-off-by: Chris Packham 
---
 drivers/edac/mv64x60_edac.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index 14b7e7b71eaa..454e1e26ee7c 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -853,8 +853,6 @@ static struct platform_driver * const drivers[] = {
 
 static int __init mv64x60_edac_init(void)
 {
-   int ret = 0;
-
printk(KERN_INFO "Marvell MV64x60 EDAC driver " MV64x60_REVISION "\n");
printk(KERN_INFO "\t(C) 2006-2007 MontaVista Software\n");
/* make sure error reporting method is sane */
-- 
2.11.0.24.ge6920cf



[PATCH 2/3] EDAC: mv64x60: Fix pdata->name

2017-05-11 Thread Chris Packham
Change this from mpc85xx_pci_err to mv64x60_pci_err.  The former is
likely a hangover from when this driver was created.

Signed-off-by: Chris Packham 
---
 drivers/edac/mv64x60_edac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
index 454e1e26ee7c..ddc5082f7577 100644
--- a/drivers/edac/mv64x60_edac.c
+++ b/drivers/edac/mv64x60_edac.c
@@ -116,7 +116,7 @@ static int mv64x60_pci_err_probe(struct platform_device 
*pdev)
pdata = pci->pvt_info;
 
pdata->pci_hose = pdev->id;
-   pdata->name = "mpc85xx_pci_err";
+   pdata->name = "mv64x60_pci_err";
platform_set_drvdata(pdev, pci);
pci->dev = &pdev->dev;
pci->dev_name = dev_name(&pdev->dev);
-- 
2.11.0.24.ge6920cf



Re: [PATCH v3 2/4] hwmon: (adt7475) fan stall prevention

2017-05-14 Thread Chris Packham
On 15/05/17 02:54, Guenter Roeck wrote:
> On 05/10/2017 08:45 PM, Chris Packham wrote:
>> By default adt7475 will stop the fans (pwm duty cycle 0%) when the
>> temperature drops past Tmin - hysteresis. Some systems want to keep the
>> fans moving even when the temperature drops so add new sysfs attributes
>> that configure the enhanced acoustics min 1-3 which allows the fans to
>> run at the minimum configure pwm duty cycle.
>>
>> Signed-off-by: Chris Packham 
>> ---
>>
>> Changes in v2:
>> - use pwmN_stall_dis as the attribute name. I think this describes the 
>> purpose
>>   pretty well. I went with a new attribute instead of overloading
>
> Almost agree. Can we use pwmN_stall_disable ?
>

Sold. I'll send a v4 of this patch with the name changed.

> Thanks,
> Guenter
>
>
>>   pwmN_auto_point1_pwm so this doesn't affect existing users.
>> Changes in v3:
>> - Fix grammar.
>> - change enh_acou to enh_acoustics



Re: [PATCH v3 3/4] hwmon: (adt7475) temperature smoothing

2017-05-14 Thread Chris Packham
On 15/05/17 03:40, Guenter Roeck wrote:
> On 05/10/2017 08:45 PM, Chris Packham wrote:
>> When enabled temperature smoothing allows ramping the fan speed over a
>> configurable period of time instead of jumping to the new speed
>> instantaneously.
>>
>> Signed-off-by: Chris Packham 
>> ---
>>
>> Changes in v2:
>> - use a single tempN_smoothing attribute
>
> This is a bit confusing. tempN suggests that the attribute would be associated
> with a given temperature, not with fan control. Not that I have a better idea
> for an attribute name, though, so unless you find a better name I am ok with 
> it.
>

The datasheet is a bit confusing in this respect.

 From the description of register 0x62:

"Assuming that PWMx is associated with the Remote 1 temperature channel, 
these bits define the maximum rate of change of the PWMx output for 
Remote 1 temperature related changes. Instead of the fan speed jumping 
instantaneously to its newly determined speed, it ramps
gracefully at the rate determined by these bits. This feature ultimately 
enhances the acoustics of the fan."

Based on my reading it's a property of the temperature input not of the 
PWM. If you changed pwmN_auto_channels_temp this setting would stay with 
the temperature sensor not the PWM.

>> Changes in v3:
>> - change enh_acou to enh_acoustics
>> - simplify show_temp_st()
>>
>>  Documentation/hwmon/adt7475 |  4 ++
>>  drivers/hwmon/adt7475.c | 93 
>> +
>>  2 files changed, 97 insertions(+)
>>
>> diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
>> index 3990bae60e78..e82b24ec4b07 100644
>> --- a/Documentation/hwmon/adt7475
>> +++ b/Documentation/hwmon/adt7475
>> @@ -114,6 +114,10 @@ minimum (i.e. auto_point1_pwm). This behaviour can be 
>> configured using the
>>  pwm[1-*]_stall_dis sysfs attribute. A value of 0 means the fans will shut 
>> off.
>>  A value of 1 means the fans will run at auto_point1_pwm.
>>
>> +The responsiveness of the ADT747x to temperature changes can be configured.
>> +This allows smoothing of the fan speed transition. To set the transition 
>> time
>> +set the value in ms in the temp[1-*]_smoothing sysfs attribute.
>> +
>>  Notes
>>  -
>>
>> diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
>> index 4d6c625fec70..f7322330789c 100644
>> --- a/drivers/hwmon/adt7475.c
>> +++ b/drivers/hwmon/adt7475.c
>> @@ -526,6 +526,90 @@ static ssize_t set_temp(struct device *dev, struct 
>> device_attribute *attr,
>>  return count;
>>  }
>>
>> +/* Assuming CONFIG6[SLOW] is 0 */
>> +static const int ad7475_st_map[] = {
>> +37500, 18800, 12500, 7500, 4700, 3100, 1600, 800,
>> +};
>> +
>> +static ssize_t show_temp_st(struct device *dev, struct device_attribute 
>> *attr,
>> +  char *buf)
>> +{
>> +struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
>> +struct i2c_client *client = to_i2c_client(dev);
>> +struct adt7475_data *data = i2c_get_clientdata(client);
>> +long val;
>> +
>> +switch (sattr->index) {
>> +case 0:
>> +val = data->enh_acoustics[0] & 0xf;
>> +break;
>> +case 1:
>> +val = (data->enh_acoustics[1] >> 4) & 0xf;
>> +break;
>> +case 2:
>> +val = data->enh_acoustics[1] & 0xf;
>> +break;
>> +default:
>> +return -EINVAL;
>
> This will never happen and, if it does, would indicate a bug, not invalid 
> input.
> I kind of dislike dead code; it just bloats the kernel. Please either use
> default: for or together with case 2:, or make it if/else.
>

Will combine default and case 2.

>> +}
>> +
>> +if (val & 0x8)
>> +return sprintf(buf, "%d\n", ad7475_st_map[val & 0x7]);
>> +else
>> +return sprintf(buf, "0\n");
>> +}
>> +
>> +static ssize_t set_temp_st(struct device *dev, struct device_attribute 
>> *attr,
>> + const char *buf, size_t count)
>> +{
>> +struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
>> +struct i2c_client *client = to_i2c_client(dev);
>> +struct adt7475_data *data = i2c_get_clientdata(client);
>> +unsigned char reg;
>> +int shift, idx;
>> +ulong val;
>> +
>> +if (kstrtoul(buf, 10, &val))
>> +re

[PATCH v4 2/3] hwmon: (adt7475) temperature smoothing

2017-05-14 Thread Chris Packham
When enabled temperature smoothing allows ramping the fan speed over a
configurable period of time instead of jumping to the new speed
instantaneously.

Signed-off-by: Chris Packham 
---
Changes in v2:
- use a single tempN_smoothing attribute
Changes in v3:
- change enh_acou to enh_acoustics
- simplify show_temp_st()
Changes in v4:
- removed dead code.
- Make the order of the smoothing attributes match the other temperature
  attributes.

Guenter,

We'd previously discussed making the smoothing values set CONFIG6[SLOW] to
expose the other set of potential values. I wasn't sure where you wanted to go
on that one.

Personally I was on the fence since the difference would only be noticeable for
the higher values. If we do want to add support for the other values it could
be done as a subsequent patch (or a v5 if you want it).

 Documentation/hwmon/adt7475 |  4 ++
 drivers/hwmon/adt7475.c | 91 +
 2 files changed, 95 insertions(+)

diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index dc0b55794c47..09d73a10644c 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -114,6 +114,10 @@ minimum (i.e. auto_point1_pwm). This behaviour can be 
configured using the
 pwm[1-*]_stall_disable sysfs attribute. A value of 0 means the fans will shut
 off. A value of 1 means the fans will run at auto_point1_pwm.
 
+The responsiveness of the ADT747x to temperature changes can be configured.
+This allows smoothing of the fan speed transition. To set the transition time
+set the value in ms in the temp[1-*]_smoothing sysfs attribute.
+
 Notes
 -
 
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 3eb8c5c2f8af..3056076fae27 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -526,6 +526,88 @@ static ssize_t set_temp(struct device *dev, struct 
device_attribute *attr,
return count;
 }
 
+/* Assuming CONFIG6[SLOW] is 0 */
+static const int ad7475_st_map[] = {
+   37500, 18800, 12500, 7500, 4700, 3100, 1600, 800,
+};
+
+static ssize_t show_temp_st(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   long val;
+
+   switch (sattr->index) {
+   case 0:
+   val = data->enh_acoustics[0] & 0xf;
+   break;
+   case 1:
+   val = (data->enh_acoustics[1] >> 4) & 0xf;
+   break;
+   case 2:
+   default:
+   val = data->enh_acoustics[1] & 0xf;
+   break;
+   }
+
+   if (val & 0x8)
+   return sprintf(buf, "%d\n", ad7475_st_map[val & 0x7]);
+   else
+   return sprintf(buf, "0\n");
+}
+
+static ssize_t set_temp_st(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   unsigned char reg;
+   int shift, idx;
+   ulong val;
+
+   if (kstrtoul(buf, 10, &val))
+   return -EINVAL;
+
+   switch (sattr->index) {
+   case 0:
+   reg = REG_ENHANCE_ACOUSTICS1;
+   shift = 0;
+   idx = 0;
+   break;
+   case 1:
+   reg = REG_ENHANCE_ACOUSTICS2;
+   shift = 0;
+   idx = 1;
+   break;
+   case 2:
+   default:
+   reg = REG_ENHANCE_ACOUSTICS2;
+   shift = 4;
+   idx = 1;
+   break;
+   }
+
+   if (val > 0) {
+   val = find_closest_descending(val, ad7475_st_map,
+ ARRAY_SIZE(ad7475_st_map));
+   val |= 0x8;
+   }
+
+   mutex_lock(&data->lock);
+
+   data->enh_acoustics[idx] &= ~(0xf << shift);
+   data->enh_acoustics[idx] |= (val << shift);
+
+   i2c_smbus_write_byte_data(client, reg, data->enh_acoustics[idx]);
+
+   mutex_unlock(&data->lock);
+
+   return count;
+}
+
 /*
  * Table of autorange values - the user will write the value in millidegrees,
  * and we'll convert it
@@ -1008,6 +1090,8 @@ static SENSOR_DEVICE_ATTR_2(temp1_crit, S_IRUGO | 
S_IWUSR, show_temp, set_temp,
THERM, 0);
 static SENSOR_DEVICE_ATTR_2(temp1_crit_hyst, S_IRUGO | S_IWUSR, show_temp,
set_temp, HYSTERSIS, 0);
+static SENSOR_DEVICE_ATTR_2(temp1_smoothing, S_IRUGO | S_IWUSR, show_temp_st,
+   set_temp_st, 0, 0);
 stati

[PATCH v4 1/3] hwmon: (adt7475) fan stall prevention

2017-05-14 Thread Chris Packham
By default adt7475 will stop the fans (pwm duty cycle 0%) when the
temperature drops past Tmin - hysteresis. Some systems want to keep the
fans moving even when the temperature drops so add new sysfs attributes
that configure the enhanced acoustics min 1-3 which allows the fans to
run at the minimum configure pwm duty cycle.

Signed-off-by: Chris Packham 
---
Changes in v2:
- use pwmN_stall_dis as the attribute name. I think this describes the purpose
  pretty well. I went with a new attribute instead of overloading
  pwmN_auto_point1_pwm so this doesn't affect existing users.
Changes in v3:
- Fix grammar.
- change enh_acou to enh_acoustics
Changes in v4:
- Change sysfs attribute to pwmN_stall_disable

 Documentation/hwmon/adt7475 |  5 +
 drivers/hwmon/adt7475.c | 50 +
 2 files changed, 55 insertions(+)

diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475
index 0502f2b464e1..dc0b55794c47 100644
--- a/Documentation/hwmon/adt7475
+++ b/Documentation/hwmon/adt7475
@@ -109,6 +109,11 @@ fan speed) is applied. PWM values range from 0 (off) to 
255 (full speed).
 Fan speed may be set to maximum when the temperature sensor associated with
 the PWM control exceeds temp#_max.
 
+At Tmin - hysteresis the PWM output can either be off (0% duty cycle) or at the
+minimum (i.e. auto_point1_pwm). This behaviour can be configured using the
+pwm[1-*]_stall_disable sysfs attribute. A value of 0 means the fans will shut
+off. A value of 1 means the fans will run at auto_point1_pwm.
+
 Notes
 -
 
diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index ec0c43fbcdce..3eb8c5c2f8af 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -79,6 +79,9 @@
 
 #define REG_TEMP_TRANGE_BASE   0x5F
 
+#define REG_ENHANCE_ACOUSTICS1 0x62
+#define REG_ENHANCE_ACOUSTICS2 0x63
+
 #define REG_PWM_MIN_BASE   0x64
 
 #define REG_TEMP_TMIN_BASE 0x67
@@ -209,6 +212,7 @@ struct adt7475_data {
u8 range[3];
u8 pwmctl[3];
u8 pwmchan[3];
+   u8 enh_acoustics[2];
 
u8 vid;
u8 vrm;
@@ -700,6 +704,43 @@ static ssize_t set_pwm(struct device *dev, struct 
device_attribute *attr,
data->pwm[sattr->nr][sattr->index] = clamp_val(val, 0, 0xFF);
i2c_smbus_write_byte_data(client, reg,
  data->pwm[sattr->nr][sattr->index]);
+   mutex_unlock(&data->lock);
+
+   return count;
+}
+
+static ssize_t show_stall_disable(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   u8 mask = BIT(5 + sattr->index);
+
+   return sprintf(buf, "%d\n", !!(data->enh_acoustics[0] & mask));
+}
+
+static ssize_t set_stall_disable(struct device *dev,
+struct device_attribute *attr, const char *buf,
+size_t count)
+{
+   struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   struct i2c_client *client = to_i2c_client(dev);
+   struct adt7475_data *data = i2c_get_clientdata(client);
+   long val;
+   u8 mask = BIT(5 + sattr->index);
+
+   if (kstrtol(buf, 10, &val))
+   return -EINVAL;
+
+   mutex_lock(&data->lock);
+
+   data->enh_acoustics[0] &= ~mask;
+   if (val)
+   data->enh_acoustics[0] |= mask;
+
+   i2c_smbus_write_byte_data(client, REG_ENHANCE_ACOUSTICS1,
+ data->enh_acoustics[0]);
 
mutex_unlock(&data->lock);
 
@@ -1028,6 +1069,8 @@ static SENSOR_DEVICE_ATTR_2(pwm1_auto_point1_pwm, S_IRUGO 
| S_IWUSR, show_pwm,
set_pwm, MIN, 0);
 static SENSOR_DEVICE_ATTR_2(pwm1_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 0);
+static SENSOR_DEVICE_ATTR_2(pwm1_stall_disable, S_IRUGO | S_IWUSR,
+   show_stall_disable, set_stall_disable, 0, 0);
 static SENSOR_DEVICE_ATTR_2(pwm2, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
1);
 static SENSOR_DEVICE_ATTR_2(pwm2_freq, S_IRUGO | S_IWUSR, show_pwmfreq,
@@ -1040,6 +1083,8 @@ static SENSOR_DEVICE_ATTR_2(pwm2_auto_point1_pwm, S_IRUGO 
| S_IWUSR, show_pwm,
set_pwm, MIN, 1);
 static SENSOR_DEVICE_ATTR_2(pwm2_auto_point2_pwm, S_IRUGO | S_IWUSR, show_pwm,
set_pwm, MAX, 1);
+static SENSOR_DEVICE_ATTR_2(pwm2_stall_disable, S_IRUGO | S_IWUSR,
+   show_stall_disable, set_stall_disable, 0, 1);
 static SENSOR_DEVICE_ATTR_2(pwm3, S_IRUGO | S_IWUSR, show_pwm, set_pwm, INPUT,
2);
 static SENSOR_DEVICE_ATTR_2(pwm3_freq

[PATCH v4 3/3] hwmon: (adt7475) add high frequency support

2017-05-14 Thread Chris Packham
Systems using 4-wire fans usually require high frequency (22.5kHz)
output on the pwm. Add 22500 as a valid option in the pwmfreq_table. In
high frequency mode the low-order bit are ignored so they can safely be
set to 0.

Signed-off-by: Chris Packham 
---
Changes in v3:
- New
Changes in v4:
- Fix pwmfreq_table array indexing

 drivers/hwmon/adt7475.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/adt7475.c b/drivers/hwmon/adt7475.c
index 3056076fae27..1baa213a60bd 100644
--- a/drivers/hwmon/adt7475.c
+++ b/drivers/hwmon/adt7475.c
@@ -934,7 +934,7 @@ static ssize_t set_pwmctrl(struct device *dev, struct 
device_attribute *attr,
 
 /* List of frequencies for the PWM */
 static const int pwmfreq_table[] = {
-   11, 14, 22, 29, 35, 44, 58, 88
+   11, 14, 22, 29, 35, 44, 58, 88, 22500
 };
 
 static ssize_t show_pwmfreq(struct device *dev, struct device_attribute *attr,
@@ -942,9 +942,10 @@ static ssize_t show_pwmfreq(struct device *dev, struct 
device_attribute *attr,
 {
struct adt7475_data *data = adt7475_update_device(dev);
struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+   int i = clamp_val(data->range[sattr->index] & 0xf, 0,
+ ARRAY_SIZE(pwmfreq_table) - 1);
 
-   return sprintf(buf, "%d\n",
-  pwmfreq_table[data->range[sattr->index] & 7]);
+   return sprintf(buf, "%d\n", pwmfreq_table[i]);
 }
 
 static ssize_t set_pwmfreq(struct device *dev, struct device_attribute *attr,
@@ -965,7 +966,7 @@ static ssize_t set_pwmfreq(struct device *dev, struct 
device_attribute *attr,
 
data->range[sattr->index] =
adt7475_read(TEMP_TRANGE_REG(sattr->index));
-   data->range[sattr->index] &= ~7;
+   data->range[sattr->index] &= ~0xf;
data->range[sattr->index] |= out;
 
i2c_smbus_write_byte_data(client, TEMP_TRANGE_REG(sattr->index),
-- 
2.11.0.24.ge6920cf



Re: [PATCH 1/3] ARM: dts: enable L2 cache parity and ecc on db-xc3-24g4xg board

2018-01-10 Thread Chris Packham
Hi Gregory,

On 10/01/18 21:24, Gregory CLEMENT wrote:
> Hi Chris,
> 
>   On mar., janv. 09 2018, Chris Packham  
> wrote:
> 
> Could you have add a (even small) message in the commit log?
> 
> Also could you improve the title by specify that it applies on
> armada-xp, like this:
> 
> ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
>

Will do.

>> Signed-off-by: Chris Packham 
>> ---
>>   arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts 
>> b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> index 06fce35d7491..00ca489fc788 100644
>> --- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> +++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> @@ -70,6 +70,11 @@
>>  };
>>   };
>>   
>> +&L2 {
>> +arm,parity-enable;
>> +marvell,ecc-enable;
> 
> It is not a problem for me to already applied the device tree change
> even if the driver is not merged yet. But I would like to have an
> acked-by on this new property by either a device tree maintainer or at
> least the EDAC maintainer, of course having both acked-by would be
> perfect ! :)

Thanks, I was hoping you would say that. That way I can keep this 
independent of the EDAC driver changes.

> 
> Thanks,
> 
> Gregory
> 
> 
> 
> 
>> +};
>> +
>>   &devbus_bootcs {
>>  status = "okay";
>>   
>> -- 
>> 2.15.1
>>
> 



Re: [PATCH 2/3] ARM: dts: mvebu: add sdram controller node to Armada-38x

2018-01-10 Thread Chris Packham
On 10/01/18 21:31, Gregory CLEMENT wrote:
> Hi Chris,
>   
>   On mar., janv. 09 2018, Chris Packham  
> wrote:
> 
>> The Armada-38x uses an SDRAM controller that is compatible with the
>> Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
>> is 32/16). The SDRAM controller registers are the same between the two
>> SoCs.
>>
>> Signed-off-by: Chris Packham 
>> ---
>>   arch/arm/boot/dts/armada-38x.dtsi | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
>> b/arch/arm/boot/dts/armada-38x.dtsi
>> index 00ff549d4e39..6d34c5ec178f 100644
>> --- a/arch/arm/boot/dts/armada-38x.dtsi
>> +++ b/arch/arm/boot/dts/armada-38x.dtsi
>> @@ -138,6 +138,11 @@
>>  #size-cells = <1>;
>>  ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x10>;
>>   
>> +sdramc@1400 {
> 
> Could you add a label? Thanks to this it would be possible to
> enable/disable it at board level in a esay way.
> 

Sure. Any suggestions for a name better than "sdramc:"?

It's probably worth adding the same label to armada-xp.dtsi and 
armada-xp-98dx3236.dtsi.

>> +compatible = 
>> "marvell,armada-xp-sdram-controller";
>> +reg = <0x1400 0x500>;
> 
> What about adding status = "disabled" ?
> 
> Thanks to this we can enable it at board level only if we really want
> it, it would avoid nasty regression on boards that don't need it, if an
> issue occurs. Unless you are sure that it is completely safe to enable
> it for everyone.

The EDAC driver (which is default n) will not probe the device if ECC 
has not been enabled so that should be safe.

Other than the EDAC driver the only other code that looks at this is in 
arch/arm/mach-mvebu/pm.c and it almost seems like an omission that this 
code is not active on armada-38x. The armada-38x platforms I have access 
to don't use suspend/resume so I can't verify this.



[PATCH v2 0/3] ARM: mvebu: dts: updates to enable EDAC

2018-01-10 Thread Chris Packham
I've split this off from my earlier series[1] this is just the dts changes that
will enable support for the EDAC series when it lands.

The Armada 38x as well as the 98dx3236 and similar switch chips with integrated
CPUs use the same SDRAM controller block as the Armada XP. The key difference
is the width of the DDR interface.

[1] - https://marc.info/?l=linux-kernel&m=151545124505964&w=2

Changes in v2:
- update commit message
- add labels to dts

Chris Packham (3):
  ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
  ARM: dts: armada-xp: add label to sdram-controller node
  ARM: dts: mvebu: add sdram controller node to Armada-38x

 arch/arm/boot/dts/armada-38x.dtsi | 5 +
 arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +
 arch/arm/boot/dts/armada-xp.dtsi  | 2 +-
 4 files changed, 12 insertions(+), 2 deletions(-)

-- 
2.15.1



[PATCH v2 3/3] ARM: dts: mvebu: add sdram controller node to Armada-38x

2018-01-10 Thread Chris Packham
The Armada-38x uses an SDRAM controller that is compatible with the
Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
is 32/16). The SDRAM controller registers are the same between the two
SoCs.

Signed-off-by: Chris Packham 
---
Changes in v2:
- Add label to sdram-controller node

 arch/arm/boot/dts/armada-38x.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
b/arch/arm/boot/dts/armada-38x.dtsi
index 00ff549d4e39..f9008c4ddd7d 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -138,6 +138,11 @@
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x10>;
 
+   sdramc: sdramc@1400 {
+   compatible = 
"marvell,armada-xp-sdram-controller";
+   reg = <0x1400 0x500>;
+   };
+
L2: cache-controller@8000 {
compatible = "arm,pl310-cache";
reg = <0x8000 0x1000>;
-- 
2.15.1



[PATCH v2 2/3] ARM: dts: armada-xp: add label to sdram-controller node

2018-01-10 Thread Chris Packham
Add the label "sdramc" to the sdram-controller nodes for the Armada-XP
and 98dx3236 SoCs.

Signed-off-by: Chris Packham 
---
Changes in v2:
- New

 arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
 arch/arm/boot/dts/armada-xp.dtsi  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi 
b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
index bdd4c7a45fbf..fe54e9d7cc90 100644
--- a/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
+++ b/arch/arm/boot/dts/armada-xp-98dx3236.dtsi
@@ -127,7 +127,7 @@
};
 
internal-regs {
-   sdramc@1400 {
+   sdramc: sdramc@1400 {
compatible = 
"marvell,armada-xp-sdram-controller";
reg = <0x1400 0x500>;
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index fa1e881266ac..3bb6e5e59fcc 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -73,7 +73,7 @@
};
 
internal-regs {
-   sdramc@1400 {
+   sdramc: sdramc@1400 {
compatible = 
"marvell,armada-xp-sdram-controller";
reg = <0x1400 0x500>;
};
-- 
2.15.1



[PATCH v2 1/3] ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg

2018-01-10 Thread Chris Packham
Enable L2 cache parity and ECC on the db-xc3-24g4xg board so that cache
operations are protected and errors can be flagged to the EDAC
subsystem.

Signed-off-by: Chris Packham 
---
Changes in v2:
- Update commit message

 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts 
b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
index 06fce35d7491..00ca489fc788 100644
--- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
+++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
@@ -70,6 +70,11 @@
};
 };
 
+&L2 {
+   arm,parity-enable;
+   marvell,ecc-enable;
+};
+
 &devbus_bootcs {
status = "okay";
 
-- 
2.15.1



Re: [PATCH v2 0/3] ARM: mvebu: dts: updates to enable EDAC

2018-01-11 Thread Chris Packham
On 11/01/18 22:14, Gregory CLEMENT wrote:
> Hi Chris,
>   
>   On jeu., janv. 11 2018, Chris Packham  
> wrote:
> 
>> I've split this off from my earlier series[1] this is just the dts changes 
>> that
>> will enable support for the EDAC series when it lands.
>>
>> The Armada 38x as well as the 98dx3236 and similar switch chips with 
>> integrated
>> CPUs use the same SDRAM controller block as the Armada XP. The key difference
>> is the width of the DDR interface.
>>
>> [1] - https://marc.info/?l=linux-kernel&m=151545124505964&w=2
> 
> The series is looks good now. For patch 1 I still wait for that
> the "marvell,,ecc-enable" property was accepted before merging it.
> 
> So I can either wait for that it was accepted before applying the series,
> or just applying patch 2 and 3 for now, as you want.

I'm happy either way. If it's easier for you to keep the 3 patches 
together that's fine by me.

> 
> Thanks,
> 
> Gregory
> 
> 
>>
>> Changes in v2:
>> - update commit message
>> - add labels to dts
>>
>> Chris Packham (3):
>>ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
>>ARM: dts: armada-xp: add label to sdram-controller node
>>ARM: dts: mvebu: add sdram controller node to Armada-38x
>>
>>   arch/arm/boot/dts/armada-38x.dtsi | 5 +
>>   arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 2 +-
>>   arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +
>>   arch/arm/boot/dts/armada-xp.dtsi  | 2 +-
>>   4 files changed, 12 insertions(+), 2 deletions(-)
>>
>> -- 
>> 2.15.1
>>
> 



[PATCH v4 6/8] EDAC: Add missing debugfs_create_x32 wrapper

2018-01-11 Thread Chris Packham
From: Jan Luebbe 

We already have wrappers for x8 and x16, so add the missing x32 one.

Signed-off-by: Jan Luebbe 
Reviewed-by: Borislav Petkov 
---
 drivers/edac/debugfs.c | 11 +++
 drivers/edac/edac_module.h |  5 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c
index 92dbb7e2320c..268ede7a60b2 100644
--- a/drivers/edac/debugfs.c
+++ b/drivers/edac/debugfs.c
@@ -161,3 +161,14 @@ struct dentry *edac_debugfs_create_x16(const char *name, 
umode_t mode,
return debugfs_create_x16(name, mode, parent, value);
 }
 EXPORT_SYMBOL_GPL(edac_debugfs_create_x16);
+
+/* Wrapper for debugfs_create_x32() */
+struct dentry *edac_debugfs_create_x32(const char *name, umode_t mode,
+  struct dentry *parent, u32 *value)
+{
+   if (!parent)
+   parent = edac_debugfs;
+
+   return debugfs_create_x32(name, mode, parent, value);
+}
+EXPORT_SYMBOL_GPL(edac_debugfs_create_x32);
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index dec88dcea036..546b16e29221 100644
--- a/drivers/edac/edac_module.h
+++ b/drivers/edac/edac_module.h
@@ -82,6 +82,8 @@ struct dentry *
 edac_debugfs_create_x8(const char *name, umode_t mode, struct dentry *parent, 
u8 *value);
 struct dentry *
 edac_debugfs_create_x16(const char *name, umode_t mode, struct dentry *parent, 
u16 *value);
+struct dentry *
+edac_debugfs_create_x32(const char *name, umode_t mode, struct dentry *parent, 
u32 *value);
 #else
 static inline int edac_debugfs_init(void)  
{ return -ENODEV; }
 static inline void edac_debugfs_exit(void) 
{ }
@@ -98,6 +100,9 @@ edac_debugfs_create_x8(const char *name, umode_t mode,
 static inline struct dentry *
 edac_debugfs_create_x16(const char *name, umode_t mode,
   struct dentry *parent, u16 *value)   
{ return NULL; }
+static inline struct dentry *
+edac_debugfs_create_x32(const char *name, umode_t mode,
+  struct dentry *parent, u32 *value)   
{ return NULL; }
 #endif
 
 /*
-- 
2.15.1



[PATCH v4 4/8] ARM: l2x0: support parity-enable/disable on aurora

2018-01-11 Thread Chris Packham
The aurora cache on the Marvell Armada-XP SoC supports the same tag
parity features as the other l2x0 cache implementations.

Signed-off-by: Chris Packham 
[j...@pengutronix.de: use aurora specific define AURORA_ACR_PARITY_EN]
Signed-off-by: Jan Luebbe 
---
 arch/arm/mm/cache-l2x0.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 7d2d2a3c67d0..b70bee74750d 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct 
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
 
+   if (of_property_read_bool(np, "arm,parity-enable")) {
+   mask |= AURORA_ACR_PARITY_EN;
+   val |= AURORA_ACR_PARITY_EN;
+   } else if (of_property_read_bool(np, "arm,parity-disable")) {
+   mask |= AURORA_ACR_PARITY_EN;
+   }
+
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
-- 
2.15.1



[PATCH v4 8/8] EDAC: armada_xp: Add support for more SoCs

2018-01-11 Thread Chris Packham
The Armada 38x and other integrated SoCs use a reduced pin count so the
width of the SDRAM interface is smaller than the Armada XP SoCs. This
means that the definition of "full" and "half" width is reduced from
64/32 to 32/16.

Signed-off-by: Chris Packham 
---
 drivers/edac/armada_xp_edac.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
index 70cff01afc8d..03a18b54467a 100644
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -341,6 +341,11 @@ static int axp_mc_probe(struct platform_device *pdev)
 
axp_mc_read_config(mci);
 
+   /* These SoCs have a reduced width bus */
+   if (of_machine_is_compatible("marvell,armada380") ||
+   of_machine_is_compatible("marvell,armadaxp-98dx3236"))
+   drvdata->width /= 2;
+
/* configure SBE threshold */
/* it seems that SBEs are not captured otherwise */
writel(1 << SDRAM_ERR_CTRL_THR_OFFSET, drvdata->base + 
SDRAM_ERR_CTRL_REG);
-- 
2.15.1



[PATCH v4 7/8] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC

2018-01-11 Thread Chris Packham
From: Jan Luebbe 

Add support for the ECC functionality as found in the DDR RAM and L2
cache controllers on the MV78230/MV78x60 SoCs. This driver has been
tested on the MV78460 (on a custom board with a DDR3 ECC DIMM).

Signed-off-by: Jan Luebbe 
---
 MAINTAINERS   |   6 +
 drivers/edac/Kconfig  |   7 +
 drivers/edac/Makefile |   1 +
 drivers/edac/armada_xp_edac.c | 639 ++
 4 files changed, 653 insertions(+)
 create mode 100644 drivers/edac/armada_xp_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 95c3fa1f520f..d4ce438ee5f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4994,6 +4994,12 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/amd64_edac*
 
+EDAC-ARMADA
+M: Jan Luebbe 
+L: linux-e...@vger.kernel.org
+S: Maintained
+F: drivers/edac/armada_xp_*
+
 EDAC-CALXEDA
 M: Robert Richter 
 L: linux-e...@vger.kernel.org
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 96afb2aeed18..48ea6373ec41 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -443,6 +443,13 @@ config EDAC_ALTERA_SDMMC
  Support for error detection and correction on the
  Altera SDMMC FIFO Memory for Altera SoCs.
 
+config EDAC_ARMADA_XP
+   bool "Marvell Armada XP DDR and L2 Cache ECC"
+   depends on MACH_MVEBU_V7
+   help
+ Support for error correction and detection on the Marvell Aramada XP
+ DDR RAM and L2 cache controllers.
+
 config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on ARCH_ZYNQ
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 0fd9ffa63299..70a093cc976e 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -76,5 +76,6 @@ obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o
 obj-$(CONFIG_EDAC_THUNDERX)+= thunderx_edac.o
 
 obj-$(CONFIG_EDAC_ALTERA)  += altera_edac.o
+obj-$(CONFIG_EDAC_ARMADA_XP)   += armada_xp_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
new file mode 100644
index ..70cff01afc8d
--- /dev/null
+++ b/drivers/edac/armada_xp_edac.c
@@ -0,0 +1,639 @@
+/*
+ * Copyright (C) 2017 Pengutronix, Jan Luebbe 
+ *
+ * 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 by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "edac_mc.h"
+#include "edac_device.h"
+#include "edac_module.h"
+
+/ EDAC MC (DDR RAM) /
+
+#define SDRAM_NUM_CS 4
+
+#define SDRAM_CONFIG_REG0x0
+#define SDRAM_CONFIG_ECC_MASK BIT(18)
+#define SDRAM_CONFIG_REGISTERED_MASK  BIT(17)
+#define SDRAM_CONFIG_BUS_WIDTH_MASK   BIT(15)
+
+#define SDRAM_ADDR_CTRL_REG 0x10
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs) (20+cs)
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_MASK(cs)   (0x1 << 
SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_ADDR_SEL_MASK(cs)BIT(16+cs)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs)  (cs*4+2)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_MASK(cs)(0x3 << 
SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs)(cs*4)
+#define SDRAM_ADDR_CTRL_STRUCT_MASK(cs)  (0x3 << 
SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs))
+
+#define SDRAM_ERR_DATA_H_REG0x40
+#define SDRAM_ERR_DATA_L_REG0x44
+
+#define SDRAM_ERR_RECV_ECC_REG  0x48
+#define SDRAM_ERR_RECV_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_CALC_ECC_REG  0x4c
+#define SDRAM_ERR_CALC_ECC_ROW_OFFSET 8
+#define SDRAM_ERR_CALC_ECC_ROW_MASK   (0x << SDRAM_ERR_CALC_ECC_ROW_OFFSET)
+#define SDRAM_ERR_CALC_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_ADDR_REG  0x50
+#define SDRAM_ERR_ADDR_BANK_OFFSET23
+#define SDRAM_ERR_ADDR_BANK_MASK  (0x7 << SDRAM_ERR_ADDR_BANK_OFFSET)
+#define SDRAM_ERR_ADDR_COL_OFFSET 8
+#define SDRAM_ERR_ADDR_COL_MASK   (0x7fff << SDRAM_ERR_ADDR_COL_OFFSET)
+#define SDRAM_ERR_ADDR_CS_OFFSET  1
+#define SDRAM_ERR_ADDR_CS_MASK(0x3 << SDRAM_ERR_ADDR_CS_OFFSET)
+#define SDRAM_ERR_ADDR_TYPE_MASK  BIT(0)
+
+#define SDRAM_ERR_CTRL_REG  0x54
+#define SDRAM_ERR_CTRL_THR_OFFSET 16
+#define SDRAM_ERR_CTRL_THR_MASK   (0xff << SDRAM_ERR_CTRL_THR_OFFSET)
+#define SDRAM_ERR_CTRL_PROP_MASK  BIT(9)
+
+#define SDRAM_ERR_SBE_COUNT_REG 0x58
+#define SDRAM_ERR_DBE_COUNT_REG 0x5c
+
+#define SDRAM_ERR_CAUSE_ERR_REG 0xd0
+#define SDRAM_ERR_CAUSE_MSG_REG 0xd8
+#define SDRAM_ERR_CAUSE_DBE_M

[PATCH v4 1/8] ARM: l2c: move cache-aurora-l2.h to asm/hardware

2018-01-11 Thread Chris Packham
From: Jan Luebbe 

This include file will be used by the AURORA EDAC code.

Signed-off-by: Jan Luebbe 
Reviewed-by: Gregory CLEMENT 
---
 arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h | 0
 arch/arm/mm/cache-l2x0.c| 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h (100%)

diff --git a/arch/arm/mm/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
similarity index 100%
rename from arch/arm/mm/cache-aurora-l2.h
rename to arch/arm/include/asm/hardware/cache-aurora-l2.h
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 808efbb89b88..a00d6f7fd34c 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -30,8 +30,8 @@
 #include 
 #include 
 #include 
+#include 
 #include "cache-tauros3.h"
-#include "cache-aurora-l2.h"
 
 struct l2c_init_data {
const char *type;
-- 
2.15.1



[PATCH v4 5/8] ARM: l2x0: add marvell,ecc-enable property for aurora

2018-01-11 Thread Chris Packham
The aurora cache on the Marvell Armada-XP SoC supports ECC protection
for the L2 data arrays. Add a "marvell,ecc-enable" device tree property
which can be used to enable this.

Signed-off-by: Chris Packham 
[j...@pengutronix.de: use aurora specific define AURORA_ACR_ECC_EN]
Signed-off-by: Jan Luebbe 
---
 Documentation/devicetree/bindings/arm/l2c2x0.txt | 2 ++
 arch/arm/mm/cache-l2x0.c | 7 +++
 2 files changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt 
b/Documentation/devicetree/bindings/arm/l2c2x0.txt
index fbe6cb21f4cf..15a84f0ba9f1 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt
@@ -76,6 +76,8 @@ Optional properties:
   specified to indicate that such transforms are precluded.
 - arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
 - arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- marvell,ecc-enable : enable ECC protection on the L2 cache
+- marvell,ecc-disable : disable ECC protection on the L2 cache
 - arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
   Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
   will randomly hang unless outer sync operations are disabled.
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index b70bee74750d..644f786e4fa9 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct 
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
 
+   if (of_property_read_bool(np, "marvell,ecc-enable")) {
+   mask |= AURORA_ACR_ECC_EN;
+   val |= AURORA_ACR_ECC_EN;
+   } else if (of_property_read_bool(np, "marvell,ecc-disable")) {
+   mask |= AURORA_ACR_ECC_EN;
+   }
+
if (of_property_read_bool(np, "arm,parity-enable")) {
mask |= AURORA_ACR_PARITY_EN;
val |= AURORA_ACR_PARITY_EN;
-- 
2.15.1



[PATCH v4 2/8] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE

2018-01-11 Thread Chris Packham
From: Jan Luebbe 

The macro name is too generic, so add a AURORA_ prefix.

Signed-off-by: Jan Luebbe 
Reviewed-by: Gregory CLEMENT 
---
 arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
 arch/arm/mm/cache-l2x0.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index c86124769831..dc5c479ec4c3 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -41,7 +41,7 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
-#define MAX_RANGE_SIZE 1024
+#define AURORA_MAX_RANGE_SIZE  1024
 
 #define AURORA_WAY_SIZE_SHIFT  2
 
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index a00d6f7fd34c..7d2d2a3c67d0 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1364,8 +1364,8 @@ static unsigned long aurora_range_end(unsigned long 
start, unsigned long end)
 * since cache range operations stall the CPU pipeline
 * until completion.
 */
-   if (end > start + MAX_RANGE_SIZE)
-   end = start + MAX_RANGE_SIZE;
+   if (end > start + AURORA_MAX_RANGE_SIZE)
+   end = start + AURORA_MAX_RANGE_SIZE;
 
/*
 * Cache range operations can't straddle a page boundary.
-- 
2.15.1



[PATCH v4 3/8] ARM: aurora-l2: add defines for parity and ECC registers

2018-01-11 Thread Chris Packham
From: Jan Luebbe 

These defines will be used by subsequent patches to add support for the
parity check and error correction functionality in the Aurora L2 cache
controller.

Signed-off-by: Jan Luebbe 
[cp: use shorter names for some #defines]
Signed-off-by: Chris Packham 
---
 arch/arm/include/asm/hardware/cache-aurora-l2.h | 48 +
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index dc5c479ec4c3..39769ffa0051 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -31,6 +31,9 @@
 #define AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU \
(3 << AURORA_ACR_REPLACEMENT_OFFSET)
 
+#define AURORA_ACR_PARITY_EN   (1 << 21)
+#define AURORA_ACR_ECC_EN  (1 << 20)
+
 #define AURORA_ACR_FORCE_WRITE_POLICY_OFFSET   0
 #define AURORA_ACR_FORCE_WRITE_POLICY_MASK \
(0x3 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
@@ -41,6 +44,51 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
+#define AURORA_ERR_CNT_REG  0x600
+#define AURORA_ERR_ATTR_CAP_REG 0x608
+#define AURORA_ERR_ADDR_CAP_REG 0x60c
+#define AURORA_ERR_WAY_CAP_REG  0x610
+#define AURORA_ERR_INJECT_CTL_REG   0x614
+#define AURORA_ERR_INJECT_MASK_REG  0x618
+
+#define AURORA_ERR_CNT_CLR_OFFSET 31
+#define AURORA_ERR_CNT_CLR\
+   (0x1 << AURORA_ERR_CNT_CLR_OFFSET)
+#define AURORA_ERR_CNT_UE_OFFSET  16
+#define AURORA_ERR_CNT_UE_MASK \
+   (0x7fff << AURORA_ERR_CNT_UE_OFFSET)
+#define AURORA_ERR_CNT_CE_OFFSET   0
+#define AURORA_ERR_CNT_CE_MASK \
+   (0x << AURORA_ERR_CNT_CE_OFFSET)
+
+#define AURORA_ERR_ATTR_SRC_OFF   16
+#define AURORA_ERR_ATTR_SRC_MSK\
+   (0x7 << AURORA_ERR_ATTR_SRC_OFF)
+#define AURORA_ERR_ATTR_TXN_OFF   12
+#define AURORA_ERR_ATTR_TXN_MSK\
+   (0xf << AURORA_ERR_ATTR_TXN_OFF)
+#define AURORA_ERR_ATTR_ERR_OFF8
+#define AURORA_ERR_ATTR_ERR_MSK\
+   (0x3 << AURORA_ERR_ATTR_ERR_OFF)
+#define AURORA_ERR_ATTR_CAP_VALID_OFF  0
+#define AURORA_ERR_ATTR_CAP_VALID  \
+   (0x1 << AURORA_ERR_ATTR_CAP_VALID_OFF)
+
+#define AURORA_ERR_ADDR_CAP_ADDR_MASK 0xffe0
+
+#define AURORA_ERR_WAY_IDX_OFF 8
+#define AURORA_ERR_WAY_IDX_MSK \
+   (0xfff << AURORA_ERR_WAY_IDX_OFF)
+#define AURORA_ERR_WAY_CAP_WAY_OFFSET  1
+#define AURORA_ERR_WAY_CAP_WAY_MASK\
+   (0xf << AURORA_ERR_WAY_CAP_WAY_OFFSET)
+
+#define AURORA_ERR_INJECT_CTL_ADDR_MASK 0xfff0
+#define AURORA_ERR_ATTR_TXN_OFF   12
+#define AURORA_ERR_INJECT_CTL_EN_MASK  0x3
+#define AURORA_ERR_INJECT_CTL_EN_PARITY0x2
+#define AURORA_ERR_INJECT_CTL_EN_ECC   0x1
+
 #define AURORA_MAX_RANGE_SIZE  1024
 
 #define AURORA_WAY_SIZE_SHIFT  2
-- 
2.15.1



Re: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants

2018-01-07 Thread Chris Packham
Hi Miquel, Ezequiel,

On 23/12/17 05:56, Ezequiel Garcia wrote:
> On 22 December 2017 at 12:53, Miquel RAYNAL
>  wrote:
>> Hello Chris,
>>
>> On Fri, 22 Dec 2017 12:19:04 +1300
>> Chris Packham  wrote:
>>
>>> From: Kalyan Kinthada 
>>>
>>> The Armada-370 based SoCs support arbitration between the NAND Flash
>>> interface and NOR (i.e. devbus) on the same chip select. However there
>>> are two guidelines that must be followed to avoid data corruption in
>>> this scenario.
>>
>> Sorry to bother you again with that but, do you actually face any
>> issue/data corruption with this scenario?
>>
> 
> Indeed. We need a description of a real world problem this patch is fixing.
> 

I totally agree. The Marvell FAE used words like "data corruption" hence 
my re-newed interest in this. I had hoped these patches would pique the 
interest of someone from Marvell's engineering team with some more info 
on how the data corruption exhibits.

I've been running some of the mtd-utils tests on my hardware and haven't 
detected any failures yet.

I think the key would be to be doing interleaved accesses between nand 
and the parallel device. I've just kicked off something I think should 
do this on my hardware but I'm unsure as to how long I should wait for 
an issue to present itself.

I'll leave it running for as long as I can today. If I find a failure 
I'll report back otherwise we can leave this patch for the mailing list 
archives waiting for an issue to be seen.



Re: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants

2018-01-07 Thread Chris Packham
On 08/01/18 11:35, Chris Packham wrote:
> Hi Miquel, Ezequiel,
> 
> On 23/12/17 05:56, Ezequiel Garcia wrote:
>> On 22 December 2017 at 12:53, Miquel RAYNAL
>>  wrote:
>>> Hello Chris,
>>>
>>> On Fri, 22 Dec 2017 12:19:04 +1300
>>> Chris Packham  wrote:
>>>
>>>> From: Kalyan Kinthada 
>>>>
>>>> The Armada-370 based SoCs support arbitration between the NAND Flash
>>>> interface and NOR (i.e. devbus) on the same chip select. However there
>>>> are two guidelines that must be followed to avoid data corruption in
>>>> this scenario.
>>>
>>> Sorry to bother you again with that but, do you actually face any
>>> issue/data corruption with this scenario?
>>>
>>
>> Indeed. We need a description of a real world problem this patch is fixing.
>>
> 
> I totally agree. The Marvell FAE used words like "data corruption" hence
> my re-newed interest in this. I had hoped these patches would pique the
> interest of someone from Marvell's engineering team with some more info
> on how the data corruption exhibits.
> 
> I've been running some of the mtd-utils tests on my hardware and haven't
> detected any failures yet.
> 
> I think the key would be to be doing interleaved accesses between nand
> and the parallel device. I've just kicked off something I think should
> do this on my hardware but I'm unsure as to how long I should wait for
> an issue to present itself.
> 
> I'll leave it running for as long as I can today. If I find a failure
> I'll report back otherwise we can leave this patch for the mailing list
> archives waiting for an issue to be seen.
> 

I've been running my test for several hours an no obvious problem has 
presented itself so I'm happy to leave it there until such time as a 
problem is observed or Marvell provide a reproduction.



[PATCH 0/3] EDAC: support for Armada 38x and 98dx3236 SoCs

2018-01-08 Thread Chris Packham
This series applies on top of Jan Lubbe's "EDAC drivers for Armada XP L2 and
DDR" series[1].

The Armada 38x as well as the 98dx3236 and similar switch chips with integrated
CPUs use the same SDRAM controller block as the Armada XP. The key difference
is the width of the DDR interface.

[1] - https://marc.info/?l=linux-edac&m=151030475715706&w=2

Chris Packham (3):
  ARM: dts: enable L2 cache parity and ecc on db-xc3-24g4xg board
  ARM: dts: mvebu: add sdram controller node to Armada-38x
  EDAC: armada_xp: Add support for more SoCs

 arch/arm/boot/dts/armada-38x.dtsi | 5 +
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +
 drivers/edac/armada_xp_edac.c | 5 +
 3 files changed, 15 insertions(+)

-- 
2.15.1



[PATCH 2/3] ARM: dts: mvebu: add sdram controller node to Armada-38x

2018-01-08 Thread Chris Packham
The Armada-38x uses an SDRAM controller that is compatible with the
Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
is 32/16). The SDRAM controller registers are the same between the two
SoCs.

Signed-off-by: Chris Packham 
---
 arch/arm/boot/dts/armada-38x.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
b/arch/arm/boot/dts/armada-38x.dtsi
index 00ff549d4e39..6d34c5ec178f 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -138,6 +138,11 @@
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x10>;
 
+   sdramc@1400 {
+   compatible = 
"marvell,armada-xp-sdram-controller";
+   reg = <0x1400 0x500>;
+   };
+
L2: cache-controller@8000 {
compatible = "arm,pl310-cache";
reg = <0x8000 0x1000>;
-- 
2.15.1



[PATCH 1/3] ARM: dts: enable L2 cache parity and ecc on db-xc3-24g4xg board

2018-01-08 Thread Chris Packham
Signed-off-by: Chris Packham 
---
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts 
b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
index 06fce35d7491..00ca489fc788 100644
--- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
+++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
@@ -70,6 +70,11 @@
};
 };
 
+&L2 {
+   arm,parity-enable;
+   marvell,ecc-enable;
+};
+
 &devbus_bootcs {
status = "okay";
 
-- 
2.15.1



[PATCH 3/3] EDAC: armada_xp: Add support for more SoCs

2018-01-08 Thread Chris Packham
The Armada 38x and other integrated SoCs use a reduced pin count so the
width of the SDRAM interface is smaller than the Armada XP SoCs. This
means that the definition of "full" and "half" width is reduced from
64/32 to 32/16.

Signed-off-by: Chris Packham 
---
 drivers/edac/armada_xp_edac.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
index cb9173b30aa9..40cef261e61b 100644
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -347,6 +347,11 @@ static int armada_xp_mc_edac_probe(struct platform_device 
*pdev)
 
armada_xp_mc_edac_read_config(mci);
 
+   /* These SoCs have a reduced width bus */
+   if (of_machine_is_compatible("marvell,armada380") ||
+   of_machine_is_compatible("marvell,armadaxp-98dx3236"))
+   drvdata->width /= 2;
+
/* configure SBE threshold */
/* it seems that SBEs are not captured otherwise */
writel(1 << SDRAM_ERR_CTRL_ERR_THR_OFFSET,
-- 
2.15.1



Re: [PATCH] EDAC, mv64x60: Remove some code duplication

2018-01-14 Thread Chris Packham
Hi Christophe,

On 14/01/18 06:17, Christophe JAILLET wrote:
> Le 13/01/2018 à 15:22, Borislav Petkov a écrit :
>> + Chris Packham who's been fixing some stuff in here too.
>>
>> On Sat, Jan 13, 2018 at 08:28:21AM +0100, Christophe JAILLET wrote:
>>> Reorder the error handling code in order to release the resources in
>>> reverse order than allocation.
>>>
>>> Introduce a new 'release_group' label in the error handling path and use
>>> it to void some code duplication.
>>>
>>> Signed-off-by: Christophe JAILLET 
>>> ---
>>>drivers/edac/mv64x60_edac.c | 7 ---
>>>1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
>>> index 3c68bb525d5d..aa5bc1d8f424 100644
>>> --- a/drivers/edac/mv64x60_edac.c
>>> +++ b/drivers/edac/mv64x60_edac.c
>>> @@ -450,8 +450,8 @@ static int mv64x60_cpu_err_probe(struct platform_device 
>>> *pdev)
>>>   "cpu", 1, NULL, 0, 0, NULL, 0,
>>>   edac_dev_idx);
>>> if (!edac_dev) {
>>> -   devres_release_group(&pdev->dev, mv64x60_cpu_err_probe);
>>> -   return -ENOMEM;
>>> +   res = -ENOMEM;
>>> +   goto release_group;
>>> }
>>>
>>> pdata = edac_dev->pvt_info;
>>> @@ -561,8 +561,9 @@ static int mv64x60_cpu_err_probe(struct platform_device 
>>> *pdev)
>>>err2:
>>> edac_device_del_device(&pdev->dev);
>>>err:
>>> -   devres_release_group(&pdev->dev, mv64x60_cpu_err_probe);
>>> edac_device_free_ctl_info(edac_dev);
>>> +release_group:
>>> +   devres_release_group(&pdev->dev, mv64x60_cpu_err_probe);
>>> return res;
>>>}
>>>
>>> -- 
>> Thanks, looks good. But looking at this driver, mv64x60_mc_err_probe()
>> and mv64x60_sram_err_probe() have the same problem too. Can you address them
>> with your patch too pls?
> Will do. mv64x60_pci_err_probe() also needs some tweaks.
> 
>> Also, if you feel like fixing more stuff in this driver, it doesn't use
>> the edac_printk() infrastructure but naked printk() calls. It could be
>> converted to it.
> I will only propose to remove a useless message and improve another one,
> but won't convert the whole driver, sorry.
> 

I take this you mean you have a system with a mv64x60 SoC? You might 
want to make yourself known to the linuxppc-dev list. A while back the 
prospects of dropping CONFIG_MV64X60 was raised[1]. I don't see anyone 
actually following through on this yet but I'm not really following 
linuxppc that closely.

[1] - https://marc.info/?l=linux-edac&m=149518763115206&w=2


Re: [PATCH v2 0/4] i2c: pca-platform: additional improvements

2018-03-22 Thread Chris Packham
On 07/12/17 23:42, Wolfram Sang wrote:
> On Sun, Oct 29, 2017 at 06:29:18PM +0100, Wolfram Sang wrote:
>> On Wed, Jul 05, 2017 at 10:13:54PM +1200, Chris Packham wrote:
>>> This series addresses some of the points identified by Andy. The series is
>>> based on top of i2c/for-next. 2 of the patches from v1 have already been
>>> applied so I've dropped them from this version.
>>>
>>> I have compile tested patch 1/1 but I don't have access to sh hardware
>>> to actually test the changes on.
>>>
>>> Chris Packham (4):
>>>sh: sh7785lcr: add GPIO lookup table for i2c controller reset
>>>i2c: pca-platform: unconditionally use devm_gpiod_get_optional
>>>i2c: pca-platform: use device_property_read_u32
>>>i2c: pca-platform: drop gpio from platform data
>>>
>>>   arch/blackfin/mach-bf561/boards/acvilon.c |  1 -
>>>   arch/sh/boards/board-sh7785lcr.c  | 11 +-
>>>   drivers/i2c/busses/i2c-pca-platform.c | 34 
>>> +--
>>>   include/linux/i2c-pca-platform.h  |  3 ---
>>>   4 files changed, 20 insertions(+), 29 deletions(-)
>>
>> Series looks good to me, too. I'd need ACKs from the SH maintainers,
>> though. Technically, from Blackfin maintainers as well. But I haven't
>> heard from them in months, so I could go without that.
> 
> Adding Rich Felker to CC...
> 

Ping. Was there any movement on this series? I think this may have been 
caught up between the holiday period and various merge windows.

Just wanted to check if there was anything I need to be doing to get 
this through.


[PATCH v7 8/9] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC

2018-11-21 Thread Chris Packham
From: Jan Luebbe 

Add support for the ECC functionality as found in the DDR RAM and L2
cache controllers on the MV78230/MV78x60 SoCs. This driver has been
tested on the MV78460 (on a custom board with a DDR3 ECC DIMM).

Signed-off-by: Jan Luebbe 
[cp use SPDX license]
Signed-off-by: Chris Packham 
Reviewed-by: Borislav Petkov 
---
 MAINTAINERS   |   6 +
 drivers/edac/Kconfig  |   7 +
 drivers/edac/Makefile |   1 +
 drivers/edac/armada_xp_edac.c | 630 ++
 4 files changed, 644 insertions(+)
 create mode 100644 drivers/edac/armada_xp_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 6c7ed26e84fa..7ae4cfa5c121 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5242,6 +5242,12 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/amd64_edac*
 
+EDAC-ARMADA
+M: Jan Luebbe 
+L: linux-e...@vger.kernel.org
+S: Maintained
+F: drivers/edac/armada_xp_*
+
 EDAC-CALXEDA
 M: Robert Richter 
 L: linux-e...@vger.kernel.org
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 57304b2e989f..4567757d9f82 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -439,6 +439,13 @@ config EDAC_ALTERA_SDMMC
  Support for error detection and correction on the
  Altera SDMMC FIFO Memory for Altera SoCs.
 
+config EDAC_ARMADA_XP
+   bool "Marvell Armada XP DDR and L2 Cache ECC"
+   depends on MACH_MVEBU_V7
+   help
+ Support for error correction and detection on the Marvell Aramada XP
+ DDR RAM and L2 cache controllers.
+
 config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on ARCH_ZYNQ
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 02b43a7d8c3e..f3ea40b0ce9c 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o
 obj-$(CONFIG_EDAC_THUNDERX)+= thunderx_edac.o
 
 obj-$(CONFIG_EDAC_ALTERA)  += altera_edac.o
+obj-$(CONFIG_EDAC_ARMADA_XP)   += armada_xp_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
 obj-$(CONFIG_EDAC_TI)  += ti_edac.o
diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
new file mode 100644
index ..3759a4fbbdee
--- /dev/null
+++ b/drivers/edac/armada_xp_edac.c
@@ -0,0 +1,630 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Pengutronix, Jan Luebbe 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "edac_mc.h"
+#include "edac_device.h"
+#include "edac_module.h"
+
+/ EDAC MC (DDR RAM) /
+
+#define SDRAM_NUM_CS 4
+
+#define SDRAM_CONFIG_REG0x0
+#define SDRAM_CONFIG_ECC_MASK BIT(18)
+#define SDRAM_CONFIG_REGISTERED_MASK  BIT(17)
+#define SDRAM_CONFIG_BUS_WIDTH_MASK   BIT(15)
+
+#define SDRAM_ADDR_CTRL_REG 0x10
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs) (20+cs)
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_MASK(cs)   (0x1 << 
SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_ADDR_SEL_MASK(cs)BIT(16+cs)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs)  (cs*4+2)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_MASK(cs)(0x3 << 
SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs)(cs*4)
+#define SDRAM_ADDR_CTRL_STRUCT_MASK(cs)  (0x3 << 
SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs))
+
+#define SDRAM_ERR_DATA_H_REG0x40
+#define SDRAM_ERR_DATA_L_REG0x44
+
+#define SDRAM_ERR_RECV_ECC_REG  0x48
+#define SDRAM_ERR_RECV_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_CALC_ECC_REG  0x4c
+#define SDRAM_ERR_CALC_ECC_ROW_OFFSET 8
+#define SDRAM_ERR_CALC_ECC_ROW_MASK   (0x << SDRAM_ERR_CALC_ECC_ROW_OFFSET)
+#define SDRAM_ERR_CALC_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_ADDR_REG  0x50
+#define SDRAM_ERR_ADDR_BANK_OFFSET23
+#define SDRAM_ERR_ADDR_BANK_MASK  (0x7 << SDRAM_ERR_ADDR_BANK_OFFSET)
+#define SDRAM_ERR_ADDR_COL_OFFSET 8
+#define SDRAM_ERR_ADDR_COL_MASK   (0x7fff << SDRAM_ERR_ADDR_COL_OFFSET)
+#define SDRAM_ERR_ADDR_CS_OFFSET  1
+#define SDRAM_ERR_ADDR_CS_MASK(0x3 << SDRAM_ERR_ADDR_CS_OFFSET)
+#define SDRAM_ERR_ADDR_TYPE_MASK  BIT(0)
+
+#define SDRAM_ERR_CTRL_REG  0x54
+#define SDRAM_ERR_CTRL_THR_OFFSET 16
+#define SDRAM_ERR_CTRL_THR_MASK   (0xff << SDRAM_ERR_CTRL_THR_OFFSET)
+#define SDRAM_ERR_CTRL_PROP_MASK  BIT(9)
+
+#define SDRAM_ERR_SBE_COUNT_REG 0x58
+#define SDRAM_ERR_DBE_COUNT_REG 0x5c
+
+#define SDRAM_ERR_CAUSE_ERR_REG 0xd0
+#define SDRAM_ERR_CAUSE_MSG_REG 0xd8
+#define SDRAM_ERR_CAUSE_DBE_MASK  BIT(1)
+#define SDRAM_ERR_CAUSE_SBE_MASK  BIT(0)
+
+#define SDRAM_RANK_CTRL_REG 0x1e0
+#define SDRAM_RANK_CTRL_EXIST_MASK(cs) BIT(cs)
+
+struct axp_mc_drvdata {
+   void __

[PATCH v7 1/9] ARM: l2c: move cache-aurora-l2.h to asm/hardware

2018-11-21 Thread Chris Packham
From: Jan Luebbe 

This include file will be used by the AURORA EDAC code.

Signed-off-by: Jan Luebbe 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Chris Packham 
---
 arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h | 0
 arch/arm/mm/cache-l2x0.c| 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h (100%)

diff --git a/arch/arm/mm/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
similarity index 100%
rename from arch/arm/mm/cache-aurora-l2.h
rename to arch/arm/include/asm/hardware/cache-aurora-l2.h
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 808efbb89b88..a00d6f7fd34c 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -30,8 +30,8 @@
 #include 
 #include 
 #include 
+#include 
 #include "cache-tauros3.h"
-#include "cache-aurora-l2.h"
 
 struct l2c_init_data {
const char *type;
-- 
2.19.1


[PATCH v7 0/9] EDAC drivers for Armada XP L2 and DDR

2018-11-21 Thread Chris Packham
The current plan is for these to go in via the ARM tree once appropriate
Reviews/Acks have been given

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525561.html

This series adds drivers for the L2 cache and DDR RAM ECC functionality as
found on the MV78230/MV78x60 SoCs. Jan has tested these changes with the
MV78460 (on a custom board with a DDR3 ECC DIMM), Chris has tested these
changes with 88F6820 and 98dx3236 (both a custom boards with fixed DDR3 + ECC).

Also contained in this series is an additional debugfs wrapper.

Compared to the previous v6 series I've dropped the marvell,ecc-disable
property.

Compared to the previous v5 series I've split the dt-binding documentation into
its own patch and updated armada_xp_edac.c to use a SPDX license.

Compared to the previous v4 series I've added my s-o-b to some of Jan's
patches and rebased against v4.19.0.

Compared to the previous v3 series, the following changes have been made:
- Use shorter names for the AURORA ECC and parity registers
- Numerous formatting changes to edac/armada_xp.c (as requested by Boris)
- Added support for Armada-38x and 98dx3236 SoCs

Compared to the previous v2 series, the following changes have been made:
- Allocate EDAC structures later during probing and drop devres support
  patches (requested by Boris)
- Make drvdata->width usage consistent according to the comment (suggested by
  Chris)

Compared to the previous v1 series, the following changes have been made:
- Add the aurora-l2 register defines earlier in the series (suggested by
  Russell King and Gregory CLEMENT )
- Changed the DT vendor prefix from "arm" to "marvell" for the 
ecc-enable/disable
  properties on the aurora-l2 (suggested by Russell King)
- Fix some warnings reported by checkpatch

Compared to the original RFC series, the following changes have been made:
- Integrated Chris' patches for parity and ECC configuration via DT
- Merged the DDR RAM and L2 cache drivers (as requested by Boris, analogous
  to fsl_ddr_edac.c and mpc85xx_edac.c)
- Added myself to MAINTAINERS (requested by Boris)
- L2 cache: Track the msg size and use snprintf (review comment by Chris)
- L2 cache: Split error injection from the check function (review comment by
  Chris)
- DDR RAM: Allow 16 bit width in addition to 32 and 64 bit (review comment by
  Chris)
- Use of_match_ptr() (review comments by Chris)
- Minor checkpatch cleanups

Chris Packham (4):
  ARM: l2x0: support parity-enable/disable on aurora
  dt-bindings: ARM: document marvell,ecc-enable binding
  ARM: l2x0: add marvell,ecc-enable property for aurora
  EDAC: armada_xp: Add support for more SoCs

Jan Luebbe (5):
  ARM: l2c: move cache-aurora-l2.h to asm/hardware
  ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  ARM: aurora-l2: add defines for parity and ECC registers
  EDAC: Add missing debugfs_create_x32 wrapper
  EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC

 .../devicetree/bindings/arm/l2c2x0.txt|   1 +
 MAINTAINERS   |   6 +
 .../asm/hardware}/cache-aurora-l2.h   |  50 +-
 arch/arm/mm/cache-l2x0.c  |  18 +-
 drivers/edac/Kconfig  |   7 +
 drivers/edac/Makefile |   1 +
 drivers/edac/armada_xp_edac.c | 635 ++
 drivers/edac/debugfs.c|  11 +
 drivers/edac/edac_module.h|   5 +
 9 files changed, 730 insertions(+), 4 deletions(-)
 rename arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h (50%)
 create mode 100644 drivers/edac/armada_xp_edac.c

-- 
2.19.1


[PATCH v7 5/9] dt-bindings: ARM: document marvell,ecc-enable binding

2018-11-21 Thread Chris Packham
Add documentation for the marvell,ecc-enable properties which can be
used to enable ECC on the Marvell aurora cache.

Signed-off-by: Chris Packham 
Reviewed-by: Rob Herring 
---

Notes:
Changes in v7:
- remove marvell,ecc-disable
Changes in v6:
- new (split binding doc from implementation).

 Documentation/devicetree/bindings/arm/l2c2x0.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt 
b/Documentation/devicetree/bindings/arm/l2c2x0.txt
index fbe6cb21f4cf..69e890d56392 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt
@@ -76,6 +76,7 @@ Optional properties:
   specified to indicate that such transforms are precluded.
 - arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
 - arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- marvell,ecc-enable : enable ECC protection on the L2 cache
 - arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
   Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
   will randomly hang unless outer sync operations are disabled.
-- 
2.19.1


[PATCH v7 6/9] ARM: l2x0: add marvell,ecc-enable property for aurora

2018-11-21 Thread Chris Packham
The aurora cache on the Marvell Armada-XP SoC supports ECC protection
for the L2 data arrays. Add a "marvell,ecc-enable" device tree property
which can be used to enable this.

Signed-off-by: Chris Packham 
[j...@pengutronix.de: use aurora specific define AURORA_ACR_ECC_EN]
Signed-off-by: Jan Luebbe 
---

Notes:
Changes in v7:
- remove marvell,ecc-disable

 arch/arm/mm/cache-l2x0.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index b70bee74750d..e5380f7b14a5 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,11 @@ static void __init aurora_of_parse(const struct 
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
 
+   if (of_property_read_bool(np, "marvell,ecc-enable")) {
+   mask |= AURORA_ACR_ECC_EN;
+   val |= AURORA_ACR_ECC_EN;
+   }
+
if (of_property_read_bool(np, "arm,parity-enable")) {
mask |= AURORA_ACR_PARITY_EN;
val |= AURORA_ACR_PARITY_EN;
-- 
2.19.1


[PATCH v7 4/9] ARM: l2x0: support parity-enable/disable on aurora

2018-11-21 Thread Chris Packham
The aurora cache on the Marvell Armada-XP SoC supports the same tag
parity features as the other l2x0 cache implementations.

Signed-off-by: Chris Packham 
[j...@pengutronix.de: use aurora specific define AURORA_ACR_PARITY_EN]
Signed-off-by: Jan Luebbe 
---
 arch/arm/mm/cache-l2x0.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 7d2d2a3c67d0..b70bee74750d 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct 
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
 
+   if (of_property_read_bool(np, "arm,parity-enable")) {
+   mask |= AURORA_ACR_PARITY_EN;
+   val |= AURORA_ACR_PARITY_EN;
+   } else if (of_property_read_bool(np, "arm,parity-disable")) {
+   mask |= AURORA_ACR_PARITY_EN;
+   }
+
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
-- 
2.19.1


[PATCH v7 9/9] EDAC: armada_xp: Add support for more SoCs

2018-11-21 Thread Chris Packham
The Armada 38x and other integrated SoCs use a reduced pin count so the
width of the SDRAM interface is smaller than the Armada XP SoCs. This
means that the definition of "full" and "half" width is reduced from
64/32 to 32/16.

Signed-off-by: Chris Packham 
---
 drivers/edac/armada_xp_edac.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
index 3759a4fbbdee..7f227bdcbc84 100644
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -332,6 +332,11 @@ static int axp_mc_probe(struct platform_device *pdev)
 
axp_mc_read_config(mci);
 
+   /* These SoCs have a reduced width bus */
+   if (of_machine_is_compatible("marvell,armada380") ||
+   of_machine_is_compatible("marvell,armadaxp-98dx3236"))
+   drvdata->width /= 2;
+
/* configure SBE threshold */
/* it seems that SBEs are not captured otherwise */
writel(1 << SDRAM_ERR_CTRL_THR_OFFSET, drvdata->base + 
SDRAM_ERR_CTRL_REG);
-- 
2.19.1


[PATCH v7 2/9] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE

2018-11-21 Thread Chris Packham
From: Jan Luebbe 

The macro name is too generic, so add a AURORA_ prefix.

Signed-off-by: Jan Luebbe 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Chris Packham 
---
 arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
 arch/arm/mm/cache-l2x0.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index c86124769831..dc5c479ec4c3 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -41,7 +41,7 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
-#define MAX_RANGE_SIZE 1024
+#define AURORA_MAX_RANGE_SIZE  1024
 
 #define AURORA_WAY_SIZE_SHIFT  2
 
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index a00d6f7fd34c..7d2d2a3c67d0 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1364,8 +1364,8 @@ static unsigned long aurora_range_end(unsigned long 
start, unsigned long end)
 * since cache range operations stall the CPU pipeline
 * until completion.
 */
-   if (end > start + MAX_RANGE_SIZE)
-   end = start + MAX_RANGE_SIZE;
+   if (end > start + AURORA_MAX_RANGE_SIZE)
+   end = start + AURORA_MAX_RANGE_SIZE;
 
/*
 * Cache range operations can't straddle a page boundary.
-- 
2.19.1


[PATCH v7 3/9] ARM: aurora-l2: add defines for parity and ECC registers

2018-11-21 Thread Chris Packham
From: Jan Luebbe 

These defines will be used by subsequent patches to add support for the
parity check and error correction functionality in the Aurora L2 cache
controller.

Signed-off-by: Jan Luebbe 
Signed-off-by: Chris Packham 
---
 .../include/asm/hardware/cache-aurora-l2.h| 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index dc5c479ec4c3..39769ffa0051 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -31,6 +31,9 @@
 #define AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU \
(3 << AURORA_ACR_REPLACEMENT_OFFSET)
 
+#define AURORA_ACR_PARITY_EN   (1 << 21)
+#define AURORA_ACR_ECC_EN  (1 << 20)
+
 #define AURORA_ACR_FORCE_WRITE_POLICY_OFFSET   0
 #define AURORA_ACR_FORCE_WRITE_POLICY_MASK \
(0x3 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
@@ -41,6 +44,51 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
+#define AURORA_ERR_CNT_REG  0x600
+#define AURORA_ERR_ATTR_CAP_REG 0x608
+#define AURORA_ERR_ADDR_CAP_REG 0x60c
+#define AURORA_ERR_WAY_CAP_REG  0x610
+#define AURORA_ERR_INJECT_CTL_REG   0x614
+#define AURORA_ERR_INJECT_MASK_REG  0x618
+
+#define AURORA_ERR_CNT_CLR_OFFSET 31
+#define AURORA_ERR_CNT_CLR\
+   (0x1 << AURORA_ERR_CNT_CLR_OFFSET)
+#define AURORA_ERR_CNT_UE_OFFSET  16
+#define AURORA_ERR_CNT_UE_MASK \
+   (0x7fff << AURORA_ERR_CNT_UE_OFFSET)
+#define AURORA_ERR_CNT_CE_OFFSET   0
+#define AURORA_ERR_CNT_CE_MASK \
+   (0x << AURORA_ERR_CNT_CE_OFFSET)
+
+#define AURORA_ERR_ATTR_SRC_OFF   16
+#define AURORA_ERR_ATTR_SRC_MSK\
+   (0x7 << AURORA_ERR_ATTR_SRC_OFF)
+#define AURORA_ERR_ATTR_TXN_OFF   12
+#define AURORA_ERR_ATTR_TXN_MSK\
+   (0xf << AURORA_ERR_ATTR_TXN_OFF)
+#define AURORA_ERR_ATTR_ERR_OFF8
+#define AURORA_ERR_ATTR_ERR_MSK\
+   (0x3 << AURORA_ERR_ATTR_ERR_OFF)
+#define AURORA_ERR_ATTR_CAP_VALID_OFF  0
+#define AURORA_ERR_ATTR_CAP_VALID  \
+   (0x1 << AURORA_ERR_ATTR_CAP_VALID_OFF)
+
+#define AURORA_ERR_ADDR_CAP_ADDR_MASK 0xffe0
+
+#define AURORA_ERR_WAY_IDX_OFF 8
+#define AURORA_ERR_WAY_IDX_MSK \
+   (0xfff << AURORA_ERR_WAY_IDX_OFF)
+#define AURORA_ERR_WAY_CAP_WAY_OFFSET  1
+#define AURORA_ERR_WAY_CAP_WAY_MASK\
+   (0xf << AURORA_ERR_WAY_CAP_WAY_OFFSET)
+
+#define AURORA_ERR_INJECT_CTL_ADDR_MASK 0xfff0
+#define AURORA_ERR_ATTR_TXN_OFF   12
+#define AURORA_ERR_INJECT_CTL_EN_MASK  0x3
+#define AURORA_ERR_INJECT_CTL_EN_PARITY0x2
+#define AURORA_ERR_INJECT_CTL_EN_ECC   0x1
+
 #define AURORA_MAX_RANGE_SIZE  1024
 
 #define AURORA_WAY_SIZE_SHIFT  2
-- 
2.19.1


[PATCH v7 7/9] EDAC: Add missing debugfs_create_x32 wrapper

2018-11-21 Thread Chris Packham
From: Jan Luebbe 

We already have wrappers for x8 and x16, so add the missing x32 one.

Signed-off-by: Jan Luebbe 
Reviewed-by: Borislav Petkov 
Signed-off-by: Chris Packham 
---
 drivers/edac/debugfs.c | 11 +++
 drivers/edac/edac_module.h |  5 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c
index 92dbb7e2320c..268ede7a60b2 100644
--- a/drivers/edac/debugfs.c
+++ b/drivers/edac/debugfs.c
@@ -161,3 +161,14 @@ struct dentry *edac_debugfs_create_x16(const char *name, 
umode_t mode,
return debugfs_create_x16(name, mode, parent, value);
 }
 EXPORT_SYMBOL_GPL(edac_debugfs_create_x16);
+
+/* Wrapper for debugfs_create_x32() */
+struct dentry *edac_debugfs_create_x32(const char *name, umode_t mode,
+  struct dentry *parent, u32 *value)
+{
+   if (!parent)
+   parent = edac_debugfs;
+
+   return debugfs_create_x32(name, mode, parent, value);
+}
+EXPORT_SYMBOL_GPL(edac_debugfs_create_x32);
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index dec88dcea036..546b16e29221 100644
--- a/drivers/edac/edac_module.h
+++ b/drivers/edac/edac_module.h
@@ -82,6 +82,8 @@ struct dentry *
 edac_debugfs_create_x8(const char *name, umode_t mode, struct dentry *parent, 
u8 *value);
 struct dentry *
 edac_debugfs_create_x16(const char *name, umode_t mode, struct dentry *parent, 
u16 *value);
+struct dentry *
+edac_debugfs_create_x32(const char *name, umode_t mode, struct dentry *parent, 
u32 *value);
 #else
 static inline int edac_debugfs_init(void)  
{ return -ENODEV; }
 static inline void edac_debugfs_exit(void) 
{ }
@@ -98,6 +100,9 @@ edac_debugfs_create_x8(const char *name, umode_t mode,
 static inline struct dentry *
 edac_debugfs_create_x16(const char *name, umode_t mode,
   struct dentry *parent, u16 *value)   
{ return NULL; }
+static inline struct dentry *
+edac_debugfs_create_x32(const char *name, umode_t mode,
+  struct dentry *parent, u32 *value)   
{ return NULL; }
 #endif
 
 /*
-- 
2.19.1


[PATCH v6 2/9] ARM: aurora-l2: add prefix to MAX_RANGE_SIZE

2018-11-08 Thread Chris Packham
From: Jan Luebbe 

The macro name is too generic, so add a AURORA_ prefix.

Signed-off-by: Jan Luebbe 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Chris Packham 
---
 arch/arm/include/asm/hardware/cache-aurora-l2.h | 2 +-
 arch/arm/mm/cache-l2x0.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index c86124769831..dc5c479ec4c3 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -41,7 +41,7 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
-#define MAX_RANGE_SIZE 1024
+#define AURORA_MAX_RANGE_SIZE  1024
 
 #define AURORA_WAY_SIZE_SHIFT  2
 
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index a00d6f7fd34c..7d2d2a3c67d0 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1364,8 +1364,8 @@ static unsigned long aurora_range_end(unsigned long 
start, unsigned long end)
 * since cache range operations stall the CPU pipeline
 * until completion.
 */
-   if (end > start + MAX_RANGE_SIZE)
-   end = start + MAX_RANGE_SIZE;
+   if (end > start + AURORA_MAX_RANGE_SIZE)
+   end = start + AURORA_MAX_RANGE_SIZE;
 
/*
 * Cache range operations can't straddle a page boundary.
-- 
2.19.1


[PATCH v6 0/9] EDAC drivers for Armada XP L2 and DDR

2018-11-08 Thread Chris Packham
The current plan is for these to go in via the ARM tree once appropriate
Reviews/Acks have been given

http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/525561.html

This series adds drivers for the L2 cache and DDR RAM ECC functionality as
found on the MV78230/MV78x60 SoCs. Jan has tested these changes with the
MV78460 (on a custom board with a DDR3 ECC DIMM), Chris has tested these
changes with 88F6820 and 98dx3236 (both a custom boards with fixed DDR3 + ECC).

Also contained in this series is an additional debugfs wrapper.

Compared to the previous v5 series I've split the dt-binding documentation into
its own patch and updated armada_xp_edac.c to use a SPDX license.

Compared to the previous v4 series I've added my s-o-b to some of Jan's
patches and rebased against v4.19.0.

Compared to the previous v3 series, the following changes have been made:
- Use shorter names for the AURORA ECC and parity registers
- Numerous formatting changes to edac/armada_xp.c (as requested by Boris)
- Added support for Armada-38x and 98dx3236 SoCs

Compared to the previous v2 series, the following changes have been made:
- Allocate EDAC structures later during probing and drop devres support
  patches (requested by Boris)
- Make drvdata->width usage consistent according to the comment (suggested by
  Chris)

Compared to the previous v1 series, the following changes have been made:
- Add the aurora-l2 register defines earlier in the series (suggested by
  Russell King and Gregory CLEMENT )
- Changed the DT vendor prefix from "arm" to "marvell" for the 
ecc-enable/disable
  properties on the aurora-l2 (suggested by Russell King)
- Fix some warnings reported by checkpatch

Compared to the original RFC series, the following changes have been made:
- Integrated Chris' patches for parity and ECC configuration via DT
- Merged the DDR RAM and L2 cache drivers (as requested by Boris, analogous
  to fsl_ddr_edac.c and mpc85xx_edac.c)
- Added myself to MAINTAINERS (requested by Boris)
- L2 cache: Track the msg size and use snprintf (review comment by Chris)
- L2 cache: Split error injection from the check function (review comment by
  Chris)
- DDR RAM: Allow 16 bit width in addition to 32 and 64 bit (review comment by
  Chris)
- Use of_match_ptr() (review comments by Chris)
- Minor checkpatch cleanups

Chris Packham (4):
  ARM: l2x0: support parity-enable/disable on aurora
  dt-bindings: ARM: document marvell,ecc-enable binding
  ARM: l2x0: add marvell,ecc-enable property for aurora
  EDAC: armada_xp: Add support for more SoCs

Jan Luebbe (5):
  ARM: l2c: move cache-aurora-l2.h to asm/hardware
  ARM: aurora-l2: add prefix to MAX_RANGE_SIZE
  ARM: aurora-l2: add defines for parity and ECC registers
  EDAC: Add missing debugfs_create_x32 wrapper
  EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC

 .../devicetree/bindings/arm/l2c2x0.txt|   2 +
 MAINTAINERS   |   6 +
 .../asm/hardware}/cache-aurora-l2.h   |  50 +-
 arch/arm/mm/cache-l2x0.c  |  20 +-
 drivers/edac/Kconfig  |   7 +
 drivers/edac/Makefile |   1 +
 drivers/edac/armada_xp_edac.c | 635 ++
 drivers/edac/debugfs.c|  11 +
 drivers/edac/edac_module.h|   5 +
 9 files changed, 733 insertions(+), 4 deletions(-)
 rename arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h (50%)
 create mode 100644 drivers/edac/armada_xp_edac.c

-- 
2.19.1


[PATCH v6 8/9] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC

2018-11-08 Thread Chris Packham
From: Jan Luebbe 

Add support for the ECC functionality as found in the DDR RAM and L2
cache controllers on the MV78230/MV78x60 SoCs. This driver has been
tested on the MV78460 (on a custom board with a DDR3 ECC DIMM).

Signed-off-by: Jan Luebbe 
[cp use SPDX license]
Signed-off-by: Chris Packham 
---
 MAINTAINERS   |   6 +
 drivers/edac/Kconfig  |   7 +
 drivers/edac/Makefile |   1 +
 drivers/edac/armada_xp_edac.c | 630 ++
 4 files changed, 644 insertions(+)
 create mode 100644 drivers/edac/armada_xp_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 6c7ed26e84fa..7ae4cfa5c121 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5242,6 +5242,12 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/amd64_edac*
 
+EDAC-ARMADA
+M: Jan Luebbe 
+L: linux-e...@vger.kernel.org
+S: Maintained
+F: drivers/edac/armada_xp_*
+
 EDAC-CALXEDA
 M: Robert Richter 
 L: linux-e...@vger.kernel.org
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 57304b2e989f..4567757d9f82 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -439,6 +439,13 @@ config EDAC_ALTERA_SDMMC
  Support for error detection and correction on the
  Altera SDMMC FIFO Memory for Altera SoCs.
 
+config EDAC_ARMADA_XP
+   bool "Marvell Armada XP DDR and L2 Cache ECC"
+   depends on MACH_MVEBU_V7
+   help
+ Support for error correction and detection on the Marvell Aramada XP
+ DDR RAM and L2 cache controllers.
+
 config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
depends on ARCH_ZYNQ
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 02b43a7d8c3e..f3ea40b0ce9c 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o
 obj-$(CONFIG_EDAC_THUNDERX)+= thunderx_edac.o
 
 obj-$(CONFIG_EDAC_ALTERA)  += altera_edac.o
+obj-$(CONFIG_EDAC_ARMADA_XP)   += armada_xp_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
 obj-$(CONFIG_EDAC_TI)  += ti_edac.o
diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
new file mode 100644
index ..3759a4fbbdee
--- /dev/null
+++ b/drivers/edac/armada_xp_edac.c
@@ -0,0 +1,630 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Pengutronix, Jan Luebbe 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "edac_mc.h"
+#include "edac_device.h"
+#include "edac_module.h"
+
+/ EDAC MC (DDR RAM) /
+
+#define SDRAM_NUM_CS 4
+
+#define SDRAM_CONFIG_REG0x0
+#define SDRAM_CONFIG_ECC_MASK BIT(18)
+#define SDRAM_CONFIG_REGISTERED_MASK  BIT(17)
+#define SDRAM_CONFIG_BUS_WIDTH_MASK   BIT(15)
+
+#define SDRAM_ADDR_CTRL_REG 0x10
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs) (20+cs)
+#define SDRAM_ADDR_CTRL_SIZE_HIGH_MASK(cs)   (0x1 << 
SDRAM_ADDR_CTRL_SIZE_HIGH_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_ADDR_SEL_MASK(cs)BIT(16+cs)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs)  (cs*4+2)
+#define SDRAM_ADDR_CTRL_SIZE_LOW_MASK(cs)(0x3 << 
SDRAM_ADDR_CTRL_SIZE_LOW_OFFSET(cs))
+#define SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs)(cs*4)
+#define SDRAM_ADDR_CTRL_STRUCT_MASK(cs)  (0x3 << 
SDRAM_ADDR_CTRL_STRUCT_OFFSET(cs))
+
+#define SDRAM_ERR_DATA_H_REG0x40
+#define SDRAM_ERR_DATA_L_REG0x44
+
+#define SDRAM_ERR_RECV_ECC_REG  0x48
+#define SDRAM_ERR_RECV_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_CALC_ECC_REG  0x4c
+#define SDRAM_ERR_CALC_ECC_ROW_OFFSET 8
+#define SDRAM_ERR_CALC_ECC_ROW_MASK   (0x << SDRAM_ERR_CALC_ECC_ROW_OFFSET)
+#define SDRAM_ERR_CALC_ECC_VALUE_MASK 0xff
+
+#define SDRAM_ERR_ADDR_REG  0x50
+#define SDRAM_ERR_ADDR_BANK_OFFSET23
+#define SDRAM_ERR_ADDR_BANK_MASK  (0x7 << SDRAM_ERR_ADDR_BANK_OFFSET)
+#define SDRAM_ERR_ADDR_COL_OFFSET 8
+#define SDRAM_ERR_ADDR_COL_MASK   (0x7fff << SDRAM_ERR_ADDR_COL_OFFSET)
+#define SDRAM_ERR_ADDR_CS_OFFSET  1
+#define SDRAM_ERR_ADDR_CS_MASK(0x3 << SDRAM_ERR_ADDR_CS_OFFSET)
+#define SDRAM_ERR_ADDR_TYPE_MASK  BIT(0)
+
+#define SDRAM_ERR_CTRL_REG  0x54
+#define SDRAM_ERR_CTRL_THR_OFFSET 16
+#define SDRAM_ERR_CTRL_THR_MASK   (0xff << SDRAM_ERR_CTRL_THR_OFFSET)
+#define SDRAM_ERR_CTRL_PROP_MASK  BIT(9)
+
+#define SDRAM_ERR_SBE_COUNT_REG 0x58
+#define SDRAM_ERR_DBE_COUNT_REG 0x5c
+
+#define SDRAM_ERR_CAUSE_ERR_REG 0xd0
+#define SDRAM_ERR_CAUSE_MSG_REG 0xd8
+#define SDRAM_ERR_CAUSE_DBE_MASK  BIT(1)
+#define SDRAM_ERR_CAUSE_SBE_MASK  BIT(0)
+
+#define SDRAM_RANK_CTRL_REG 0x1e0
+#define SDRAM_RANK_CTRL_EXIST_MASK(cs) BIT(cs)
+
+struct axp_mc_drvdata {
+   void __iomem *base;
+   /* widt

[PATCH v6 4/9] ARM: l2x0: support parity-enable/disable on aurora

2018-11-08 Thread Chris Packham
The aurora cache on the Marvell Armada-XP SoC supports the same tag
parity features as the other l2x0 cache implementations.

Signed-off-by: Chris Packham 
[j...@pengutronix.de: use aurora specific define AURORA_ACR_PARITY_EN]
Signed-off-by: Jan Luebbe 
---
 arch/arm/mm/cache-l2x0.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 7d2d2a3c67d0..b70bee74750d 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct 
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
 
+   if (of_property_read_bool(np, "arm,parity-enable")) {
+   mask |= AURORA_ACR_PARITY_EN;
+   val |= AURORA_ACR_PARITY_EN;
+   } else if (of_property_read_bool(np, "arm,parity-disable")) {
+   mask |= AURORA_ACR_PARITY_EN;
+   }
+
*aux_val &= ~mask;
*aux_val |= val;
*aux_mask &= ~mask;
-- 
2.19.1


[PATCH v6 9/9] EDAC: armada_xp: Add support for more SoCs

2018-11-08 Thread Chris Packham
The Armada 38x and other integrated SoCs use a reduced pin count so the
width of the SDRAM interface is smaller than the Armada XP SoCs. This
means that the definition of "full" and "half" width is reduced from
64/32 to 32/16.

Signed-off-by: Chris Packham 
---
 drivers/edac/armada_xp_edac.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/edac/armada_xp_edac.c b/drivers/edac/armada_xp_edac.c
index 3759a4fbbdee..7f227bdcbc84 100644
--- a/drivers/edac/armada_xp_edac.c
+++ b/drivers/edac/armada_xp_edac.c
@@ -332,6 +332,11 @@ static int axp_mc_probe(struct platform_device *pdev)
 
axp_mc_read_config(mci);
 
+   /* These SoCs have a reduced width bus */
+   if (of_machine_is_compatible("marvell,armada380") ||
+   of_machine_is_compatible("marvell,armadaxp-98dx3236"))
+   drvdata->width /= 2;
+
/* configure SBE threshold */
/* it seems that SBEs are not captured otherwise */
writel(1 << SDRAM_ERR_CTRL_THR_OFFSET, drvdata->base + 
SDRAM_ERR_CTRL_REG);
-- 
2.19.1


[PATCH v6 5/9] dt-bindings: ARM: document marvell,ecc-enable binding

2018-11-08 Thread Chris Packham
Add documentation for the marvell,ecc-enable and marvell,ecc-disable
properties which can be used to enable/disable ECC on the Marvell aurora
cache.

Signed-off-by: Chris Packham 
---

Notes:
Changes in v6:
- new (split binding doc from implementation).

 Documentation/devicetree/bindings/arm/l2c2x0.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/l2c2x0.txt 
b/Documentation/devicetree/bindings/arm/l2c2x0.txt
index fbe6cb21f4cf..15a84f0ba9f1 100644
--- a/Documentation/devicetree/bindings/arm/l2c2x0.txt
+++ b/Documentation/devicetree/bindings/arm/l2c2x0.txt
@@ -76,6 +76,8 @@ Optional properties:
   specified to indicate that such transforms are precluded.
 - arm,parity-enable : enable parity checking on the L2 cache (L220 or PL310).
 - arm,parity-disable : disable parity checking on the L2 cache (L220 or PL310).
+- marvell,ecc-enable : enable ECC protection on the L2 cache
+- marvell,ecc-disable : disable ECC protection on the L2 cache
 - arm,outer-sync-disable : disable the outer sync operation on the L2 cache.
   Some core tiles, especially ARM PB11MPCore have a faulty L220 cache that
   will randomly hang unless outer sync operations are disabled.
-- 
2.19.1


[PATCH v6 7/9] EDAC: Add missing debugfs_create_x32 wrapper

2018-11-08 Thread Chris Packham
From: Jan Luebbe 

We already have wrappers for x8 and x16, so add the missing x32 one.

Signed-off-by: Jan Luebbe 
Reviewed-by: Borislav Petkov 
Signed-off-by: Chris Packham 
---
 drivers/edac/debugfs.c | 11 +++
 drivers/edac/edac_module.h |  5 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c
index 92dbb7e2320c..268ede7a60b2 100644
--- a/drivers/edac/debugfs.c
+++ b/drivers/edac/debugfs.c
@@ -161,3 +161,14 @@ struct dentry *edac_debugfs_create_x16(const char *name, 
umode_t mode,
return debugfs_create_x16(name, mode, parent, value);
 }
 EXPORT_SYMBOL_GPL(edac_debugfs_create_x16);
+
+/* Wrapper for debugfs_create_x32() */
+struct dentry *edac_debugfs_create_x32(const char *name, umode_t mode,
+  struct dentry *parent, u32 *value)
+{
+   if (!parent)
+   parent = edac_debugfs;
+
+   return debugfs_create_x32(name, mode, parent, value);
+}
+EXPORT_SYMBOL_GPL(edac_debugfs_create_x32);
diff --git a/drivers/edac/edac_module.h b/drivers/edac/edac_module.h
index dec88dcea036..546b16e29221 100644
--- a/drivers/edac/edac_module.h
+++ b/drivers/edac/edac_module.h
@@ -82,6 +82,8 @@ struct dentry *
 edac_debugfs_create_x8(const char *name, umode_t mode, struct dentry *parent, 
u8 *value);
 struct dentry *
 edac_debugfs_create_x16(const char *name, umode_t mode, struct dentry *parent, 
u16 *value);
+struct dentry *
+edac_debugfs_create_x32(const char *name, umode_t mode, struct dentry *parent, 
u32 *value);
 #else
 static inline int edac_debugfs_init(void)  
{ return -ENODEV; }
 static inline void edac_debugfs_exit(void) 
{ }
@@ -98,6 +100,9 @@ edac_debugfs_create_x8(const char *name, umode_t mode,
 static inline struct dentry *
 edac_debugfs_create_x16(const char *name, umode_t mode,
   struct dentry *parent, u16 *value)   
{ return NULL; }
+static inline struct dentry *
+edac_debugfs_create_x32(const char *name, umode_t mode,
+  struct dentry *parent, u32 *value)   
{ return NULL; }
 #endif
 
 /*
-- 
2.19.1


[PATCH v6 3/9] ARM: aurora-l2: add defines for parity and ECC registers

2018-11-08 Thread Chris Packham
From: Jan Luebbe 

These defines will be used by subsequent patches to add support for the
parity check and error correction functionality in the Aurora L2 cache
controller.

Signed-off-by: Jan Luebbe 
Signed-off-by: Chris Packham 
---
 .../include/asm/hardware/cache-aurora-l2.h| 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm/include/asm/hardware/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
index dc5c479ec4c3..39769ffa0051 100644
--- a/arch/arm/include/asm/hardware/cache-aurora-l2.h
+++ b/arch/arm/include/asm/hardware/cache-aurora-l2.h
@@ -31,6 +31,9 @@
 #define AURORA_ACR_REPLACEMENT_TYPE_SEMIPLRU \
(3 << AURORA_ACR_REPLACEMENT_OFFSET)
 
+#define AURORA_ACR_PARITY_EN   (1 << 21)
+#define AURORA_ACR_ECC_EN  (1 << 20)
+
 #define AURORA_ACR_FORCE_WRITE_POLICY_OFFSET   0
 #define AURORA_ACR_FORCE_WRITE_POLICY_MASK \
(0x3 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
@@ -41,6 +44,51 @@
 #define AURORA_ACR_FORCE_WRITE_THRO_POLICY \
(2 << AURORA_ACR_FORCE_WRITE_POLICY_OFFSET)
 
+#define AURORA_ERR_CNT_REG  0x600
+#define AURORA_ERR_ATTR_CAP_REG 0x608
+#define AURORA_ERR_ADDR_CAP_REG 0x60c
+#define AURORA_ERR_WAY_CAP_REG  0x610
+#define AURORA_ERR_INJECT_CTL_REG   0x614
+#define AURORA_ERR_INJECT_MASK_REG  0x618
+
+#define AURORA_ERR_CNT_CLR_OFFSET 31
+#define AURORA_ERR_CNT_CLR\
+   (0x1 << AURORA_ERR_CNT_CLR_OFFSET)
+#define AURORA_ERR_CNT_UE_OFFSET  16
+#define AURORA_ERR_CNT_UE_MASK \
+   (0x7fff << AURORA_ERR_CNT_UE_OFFSET)
+#define AURORA_ERR_CNT_CE_OFFSET   0
+#define AURORA_ERR_CNT_CE_MASK \
+   (0x << AURORA_ERR_CNT_CE_OFFSET)
+
+#define AURORA_ERR_ATTR_SRC_OFF   16
+#define AURORA_ERR_ATTR_SRC_MSK\
+   (0x7 << AURORA_ERR_ATTR_SRC_OFF)
+#define AURORA_ERR_ATTR_TXN_OFF   12
+#define AURORA_ERR_ATTR_TXN_MSK\
+   (0xf << AURORA_ERR_ATTR_TXN_OFF)
+#define AURORA_ERR_ATTR_ERR_OFF8
+#define AURORA_ERR_ATTR_ERR_MSK\
+   (0x3 << AURORA_ERR_ATTR_ERR_OFF)
+#define AURORA_ERR_ATTR_CAP_VALID_OFF  0
+#define AURORA_ERR_ATTR_CAP_VALID  \
+   (0x1 << AURORA_ERR_ATTR_CAP_VALID_OFF)
+
+#define AURORA_ERR_ADDR_CAP_ADDR_MASK 0xffe0
+
+#define AURORA_ERR_WAY_IDX_OFF 8
+#define AURORA_ERR_WAY_IDX_MSK \
+   (0xfff << AURORA_ERR_WAY_IDX_OFF)
+#define AURORA_ERR_WAY_CAP_WAY_OFFSET  1
+#define AURORA_ERR_WAY_CAP_WAY_MASK\
+   (0xf << AURORA_ERR_WAY_CAP_WAY_OFFSET)
+
+#define AURORA_ERR_INJECT_CTL_ADDR_MASK 0xfff0
+#define AURORA_ERR_ATTR_TXN_OFF   12
+#define AURORA_ERR_INJECT_CTL_EN_MASK  0x3
+#define AURORA_ERR_INJECT_CTL_EN_PARITY0x2
+#define AURORA_ERR_INJECT_CTL_EN_ECC   0x1
+
 #define AURORA_MAX_RANGE_SIZE  1024
 
 #define AURORA_WAY_SIZE_SHIFT  2
-- 
2.19.1


[PATCH v6 1/9] ARM: l2c: move cache-aurora-l2.h to asm/hardware

2018-11-08 Thread Chris Packham
From: Jan Luebbe 

This include file will be used by the AURORA EDAC code.

Signed-off-by: Jan Luebbe 
Reviewed-by: Gregory CLEMENT 
Signed-off-by: Chris Packham 
---
 arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h | 0
 arch/arm/mm/cache-l2x0.c| 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/arm/{mm => include/asm/hardware}/cache-aurora-l2.h (100%)

diff --git a/arch/arm/mm/cache-aurora-l2.h 
b/arch/arm/include/asm/hardware/cache-aurora-l2.h
similarity index 100%
rename from arch/arm/mm/cache-aurora-l2.h
rename to arch/arm/include/asm/hardware/cache-aurora-l2.h
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 808efbb89b88..a00d6f7fd34c 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -30,8 +30,8 @@
 #include 
 #include 
 #include 
+#include 
 #include "cache-tauros3.h"
-#include "cache-aurora-l2.h"
 
 struct l2c_init_data {
const char *type;
-- 
2.19.1


[PATCH v6 6/9] ARM: l2x0: add marvell,ecc-enable property for aurora

2018-11-08 Thread Chris Packham
The aurora cache on the Marvell Armada-XP SoC supports ECC protection
for the L2 data arrays. Add a "marvell,ecc-enable" device tree property
which can be used to enable this.

Signed-off-by: Chris Packham 
[j...@pengutronix.de: use aurora specific define AURORA_ACR_ECC_EN]
Signed-off-by: Jan Luebbe 
---
 arch/arm/mm/cache-l2x0.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index b70bee74750d..644f786e4fa9 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -1505,6 +1505,13 @@ static void __init aurora_of_parse(const struct 
device_node *np,
mask |= AURORA_ACR_FORCE_WRITE_POLICY_MASK;
}
 
+   if (of_property_read_bool(np, "marvell,ecc-enable")) {
+   mask |= AURORA_ACR_ECC_EN;
+   val |= AURORA_ACR_ECC_EN;
+   } else if (of_property_read_bool(np, "marvell,ecc-disable")) {
+   mask |= AURORA_ACR_ECC_EN;
+   }
+
if (of_property_read_bool(np, "arm,parity-enable")) {
mask |= AURORA_ACR_PARITY_EN;
val |= AURORA_ACR_PARITY_EN;
-- 
2.19.1


Re: [PATCH v6 5/9] dt-bindings: ARM: document marvell,ecc-enable binding

2018-11-11 Thread Chris Packham
On 10/11/18 4:58 AM, Arnd Bergmann wrote:
> On Fri, Nov 9, 2018 at 12:48 PM Russell King - ARM Linux
>  wrote:
>>
>> On Fri, Nov 09, 2018 at 12:40:06PM +0100, Arnd Bergmann wrote:
>>> On Fri, Nov 9, 2018 at 8:04 AM Chris Packham
>>>  wrote:
>>>>
>>>> Add documentation for the marvell,ecc-enable and marvell,ecc-disable
>>>> properties which can be used to enable/disable ECC on the Marvell aurora
>>>> cache.
>>>>
>>>> Signed-off-by: Chris Packham 
>>>> ---
>>>
>>> Why do you need both enable and disable? Wouldn't one of them be enough 
>>> here?
>>
>> It isn't an "on when ecc-enable is present, off when not" because the
>> current behaviour is to preserve these bits in the control register.
>>
>> If we were to implement it as "if no ecc-enable property, turn off
>> ECC" then that would drastically change the behaviour - systems which
>> were configured for ECC suddenly lose ECC support.
>>
>> Since we don't know which have it and which don't, we can't implement
>> the option like that.
> 
> What I meant was why we need support force-disabling it. I understand
> that we need to allow leaving it at the boot-time default as well as
> force-enabling it.

I added ecc-disable because I was modeling it after 
arm,parity-enable/arm,parity-disable. The only reason I can imagine 
wanting to force disable this would be some mis-behaving SoC which has 
it enabled by default in hardware, to my knowledge no such system exists 
(that would use this driver).

I'd be happy to drop the binding an implementation and send a v7 if you 
feel strongly that it marvell,ecc-disable should be removed.


Re: [PATCH v6 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

2018-07-08 Thread Chris Packham
Hi Boris,

On 07/07/18 09:37, Boris Brezillon wrote:
> On Fri, 6 Jul 2018 21:27:20 +0200
> Boris Brezillon  wrote:
> 
>> On Mon, 25 Jun 2018 10:44:42 +1200
>> Chris Packham  wrote:
>>
>>> Hi,
>>>
>>> I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
>>
>> Hm, it's even worse than I thought. The model name does not include the
>> -ITE suffix (E means ECC can't be disabled), which means we have no way
>> to detect the version with forced on-die ECC.
>>
>> I see 2 solutions to this problem:
>> 1/ Bean provides us a solution to reliably detect when ECC can be
>> de-actived and when it can't
>> 2/ We only ever expose 64 bytes of OOB to the user and consider that
>> ECC can be disabled, even if it can't in reality
>>
> 
> After reading the doc again, I forgot one thing you can try before
> deciding to go for option #2.
> 
> 8th bit in byte 5 of READID's result encodes whether the on-die ECC
> state (enabled or not). I remember we had a discussion with Bean where
> he told us this was a runtime status reflecting the on-die ECC state,
> which is crazy, since READID might return different values depending on
> the NAND state, and most of the code in the core assumes READID
> provides a fixed ID that encodes the chip characteristics/capabilities,
> not its state.
> 
> Anyway, if this bit is actually reflecting the on-die ECC state and
> on-die cannot be disabled on your chip, it should stay at 1 even after
> you have sent the SET_FEATURES(DISABLE_ECC) command. Let's hope this
> works as I expect, otherwise we're back to option #2 until Bean suggest
> something else.
> 

I'm away from work this week so I don't have access to that system. But 
I can take a look when I get back. From memory though there was very 
little that you could tell from the id/params on this chip (FYI we've 
decided to use a chip from a different vendor for production).


[RFC PATCH 2/2] mtd: rawnand: marvell: Support page size of 2048 with 8-bit ECC

2018-06-17 Thread Chris Packham
The MT29F1G08ABAFAWP-ITE:F chip has 2048 byte pages and requires a
minimum ECC strength of 8-bits. Allow for this combination of
requirements using the marvell_nand controller.

Signed-off-by: Chris Packham 
---
I've tried to follow the recommended AN-379 from Marvell. They do seem
to have information that covers this particular set of chip requirements
but I'm not confident I've translated their code correctly into the
current marvell_nand implementation.

This is enough to make the nand_scan work but ubi/ubifs fails to initialise
and/or mount so I may have something completely wrong. This may also be
because this chip has internal ECC enabled which cannot be disabled. I
turned up an old thread on this from April last year[1] but I didn't see
anything resulting from this. Can this combination of ECC
implementations even co-exist?

[1] - http://lists.infradead.org/pipermail/linux-mtd/2017-April/073370.html

 drivers/mtd/nand/raw/marvell_nand.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/nand/raw/marvell_nand.c 
b/drivers/mtd/nand/raw/marvell_nand.c
index ebb1d141b900..5712df553a8e 100644
--- a/drivers/mtd/nand/raw/marvell_nand.c
+++ b/drivers/mtd/nand/raw/marvell_nand.c
@@ -217,6 +217,7 @@ static const struct marvell_hw_ecc_layout 
marvell_nfc_layouts[] = {
MARVELL_LAYOUT(  512,   512,  1,  1,  1,  512,  8,  8,  0,  0,  0),
MARVELL_LAYOUT( 2048,   512,  1,  1,  1, 2048, 40, 24,  0,  0,  0),
MARVELL_LAYOUT( 2048,   512,  4,  1,  1, 2048, 32, 30,  0,  0,  0),
+   MARVELL_LAYOUT( 2048,   512,  8,  1,  1, 1024, 0, 30,  1024,  32,  30),
MARVELL_LAYOUT( 4096,   512,  4,  2,  2, 2048, 32, 30,  0,  0,  0),
MARVELL_LAYOUT( 4096,   512,  8,  5,  4, 1024,  0, 30,  0, 64, 30),
 };
-- 
2.17.1



[RFC PATCH 0/2] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

2018-06-17 Thread Chris Packham
Hi,

I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
to one of our boards which uses the Marvell NFCv2 controller.

This particular chip is a bit odd in that the datasheet states support
for ONFI 1.0 but the revision number field is 00 00. It also is marked
ABAFA but reports internally as ABAGA. Finally it has internal 8-bit ECC
which cannot be disabled.

I think that last point may cause some hassle since the internal ECC
implementation is probably not compatible with the Marvell NFCv2
implementation.

This series is very much RFC because even with these changes so far I
don't have a working system.

Here's a dump of the parameter page if anyone is interested

: 4f 4e 46 49 00 00 18 00 3f 00 00 00 00 00 00 00 ONFI?...
0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
0020: 4d 49 43 52 4f 4e 20 20 20 20 20 20 4d 54 32 39  MICRON MT29
0030: 46 31 47 30 38 41 42 41 47 41 57 50 20 20 20 20  F1G08ABAGAWP
0040: 2c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ,...
0050: 00 08 00 00 80 00 00 02 00 00 20 00 40 00 00 00  ..  .@...
0060: 00 04 00 00 01 22 01 14 00 01 05 08 00 00 04 00 ."..
0070: 08 01 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 
0080: 08 3f 00 3f 00 58 02 10 27 46 00 64 00 00 00 00 .?.?.X..'F.d
0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00a0: 00 00 00 00 01 00 00 00 00 02 04 80 01 81 04 03 
00b0: 02 01 1e 90 00 00 00 00 00 00 00 00 00 00 00 00 
00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 85 a6 ....

Chris Packham (2):
  mtd: rawnand: handle ONFI revision number field being 0
  mtd: rawnand: marvell: Support page size of 2048 with 8-bit ECC

 drivers/mtd/nand/raw/marvell_nand.c | 1 +
 drivers/mtd/nand/raw/nand_base.c| 2 ++
 2 files changed, 3 insertions(+)

-- 
2.17.1



[RFC PATCH 1/2] mtd: rawnand: handle ONFI revision number field being 0

2018-06-17 Thread Chris Packham
Some Micron NAND chips (MT29F1G08ABAFAWP-ITE:F) report 00 00 for the
revision number field of the ONFI parameter page. Rather than rejecting
these outright assume ONFI version 1.0 if the revision number is 00 00.

Signed-off-by: Chris Packham 
---
At the moment I haven't qualified this check on anything, I should
probably at least include vendor == MICRON.

As far as I can tell revision number == 0 is not permitted by the ONFI
spec but this wouldn't be the first time a vendor has ignored a spec. On
the other hand maybe I'm reading the spec wrong and someone here will
say "oh 0 means ...".

 drivers/mtd/nand/raw/nand_base.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 0cd3e216b95c..1691c7005ae4 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -5184,6 +5184,8 @@ static int nand_flash_detect_onfi(struct nand_chip *chip)
chip->parameters.onfi.version = 20;
else if (val & (1 << 1))
chip->parameters.onfi.version = 10;
+   else if (val == 0)
+   chip->parameters.onfi.version = 10;
 
if (!chip->parameters.onfi.version) {
pr_info("unsupported ONFI version: %d\n", val);
-- 
2.17.1



Re: [RFC PATCH 0/2] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

2018-06-18 Thread Chris Packham
On 19/06/18 01:15, Miquel Raynal wrote:
> Hi Chris,
> 
> On Mon, 18 Jun 2018 16:52:53 +1200, Chris Packham
>  wrote:
> 
>> Hi,
>>
>> I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
>> to one of our boards which uses the Marvell NFCv2 controller.
>>
>> This particular chip is a bit odd in that the datasheet states support
>> for ONFI 1.0 but the revision number field is 00 00. It also is marked
>> ABAFA but reports internally as ABAGA. Finally it has internal 8-bit ECC
>> which cannot be disabled.
> 
> Boris and I agree that in this case, the chip should not be probed if
> ecc->type != ON_DIE (and eventually NONE).
> 
> This should be handled in the Micron driver.
> 
> Also, what is the returned value of micron_supports_on_die_ecc() (with
> patch 1/2)?

micron_supports_on_die_ecc() returns MICRON_ON_DIE_UNSUPPORTED. 
Technically this chip should be MICRON_ON_DIE_MANDATORY since it can't 
be disabled but that wouldn't be much help since that would still result 
in -EINVAL. I'll dig into micron_supports_on_die_ecc() and see if I can 
find something in the datasheet to use.

> 
> Regards,
> Miquèl
> 



Re: [RFC PATCH 0/2] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F

2018-06-18 Thread Chris Packham
On 19/06/18 12:35, Chris Packham wrote:
> On 19/06/18 01:15, Miquel Raynal wrote:
>> Hi Chris,
>>
>> On Mon, 18 Jun 2018 16:52:53 +1200, Chris Packham
>>  wrote:
>>
>>> Hi,
>>>
>>> I'm looking at adding support for the Micron MT29F1G08ABAFAWP-ITE:F chip
>>> to one of our boards which uses the Marvell NFCv2 controller.
>>>
>>> This particular chip is a bit odd in that the datasheet states support
>>> for ONFI 1.0 but the revision number field is 00 00. It also is marked
>>> ABAFA but reports internally as ABAGA. Finally it has internal 8-bit ECC
>>> which cannot be disabled.
>>
>> Boris and I agree that in this case, the chip should not be probed if
>> ecc->type != ON_DIE (and eventually NONE).
>>
>> This should be handled in the Micron driver.
>>
>> Also, what is the returned value of micron_supports_on_die_ecc() (with
>> patch 1/2)?
> 
> micron_supports_on_die_ecc() returns MICRON_ON_DIE_UNSUPPORTED.
> Technically this chip should be MICRON_ON_DIE_MANDATORY since it can't
> be disabled but that wouldn't be much help since that would still result
> in -EINVAL. I'll dig into micron_supports_on_die_ecc() and see if I can
> find something in the datasheet to use.
> 

Some further debugging. Nothing (in 4.17) calls 
set_bit(ONFI_FEATURE_ON_DIE_ECC) so I don't think 
micron_supports_on_die_ecc() can return anything other than 
MICRON_ON_DIE_UNSUPPORTED, unless I'm missing something for how the 
{get,set}_feature_list is populated.

With the onfi.version fix and the following

--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -66,7 +66,9 @@ static int micron_nand_onfi_init(struct nand_chip *chip)

 if (p->supports_set_get_features) {
 set_bit(ONFI_FEATURE_ADDR_READ_RETRY, p->set_feature_list);
+   set_bit(ONFI_FEATURE_ON_DIE_ECC, p->set_feature_list);
 set_bit(ONFI_FEATURE_ADDR_READ_RETRY, p->get_feature_list);
+   set_bit(ONFI_FEATURE_ON_DIE_ECC, p->get_feature_list);
 }
@@ -240,7 +246,7 @@ static int micron_supports_on_die_ecc(struct 
nand_chip *chip)
  * Some Micron NANDs have an on-die ECC of 4/512, some other
- * 8/512. We only support the former.
+ * 8/512.
  */
-   if (chip->ecc_strength_ds != 4)
+   if (chip->ecc_strength_ds != 4 && chip->ecc_strength_ds != 8)
 return MICRON_ON_DIE_UNSUPPORTED;

I can get micron_supports_on_die_ecc() to return MICRON_ON_DIE_SUPPORTED.

Then I run into a problem with the marvell_nand.c which currently 
doesn't handle NAND_ECC_ON_DIE which is easily fixed.

But then I have the issue that I need to handle systems with either type 
of ECC scheme ("on-die" or "hw") which I'm not sure is even possible 
within the dts.

I'll re-base against 4.18-rc1 and send what I have so-far.


  1   2   3   4   5   6   7   8   9   >