RE: [PATCH v5 0/3] NAND support for Broadcom NS2 SoC
+Arnd, +Olof Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] arm64: Simple additions to NS2 DT
+Arnd, +Olof Ping? Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
> -Original Message- > From: Brian Norris [mailto:computersforpe...@gmail.com] > Sent: 31 October 2015 01:18 > To: Anup Patel > Cc: David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark Rutland; > Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui; > Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep > Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel; > bcm-kernel-feedback-list > Subject: Re: [PATCH v5 2/3] mtd: brcmnand: Force 8bit mode before doing > nand_scan_ident() > > On Fri, Oct 30, 2015 at 12:29:20PM +0530, Anup Patel wrote: > > Just like other NAND controllers, > > ^^ That part isn't strictly true. While READ ID data only comes out on the > lower 8 > bits, that doesn't *actually* mean you can't get valid data from a 16-bit bus > in > general; you just have to drop the upper 8 bits. That's what these two commits > did for read ID and parameter page read commands: > > commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7 > Author: Brian Norris > Date: Wed Jan 29 14:08:12 2014 -0800 > > mtd: nand: force NAND_CMD_READID onto 8-bit bus > > commit bd9c6e99b58255b9de1982711ac9487c9a2f18be > Author: Brian Norris > Date: Fri Nov 29 22:04:28 2013 -0800 > > mtd: nand: don't use read_buf for 8-bit ONFI transfers > > > the NAND READID command only works > > in 8bit mode for all versions of BRCMNAND controller. > > But I presume *this* statement is actually true. This NAND controller doesn't > exactly give us a fully-flexible READID / read_byte / read_word command, as it > works at a higher level than that (although LOW_LEVEL_OP gives us this > flexibility now). I could imagine (though I never tested 16-bit NAND) that > 16-bit > READID is broken. > > BTW, did you ask the HW designer about this? It'd be nice to be 100% sure. Yes, we had a discussed with HW designers and they confirmed that READID command will only work in 8bit mode. Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 0/3] NAND support for Broadcom NS2 SoC
> -Original Message- > From: Brian Norris [mailto:computersforpe...@gmail.com] > Sent: 31 October 2015 01:02 > To: Anup Patel > Cc: David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark Rutland; > Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui; > Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep > Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel; > bcm-kernel-feedback-list > Subject: Re: [PATCH v5 0/3] NAND support for Broadcom NS2 SoC > > On Fri, Oct 30, 2015 at 12:29:18PM +0530, Anup Patel wrote: > > We enable NAND support for Broadcom NS2 SoC by reusing existing > > BRCMNAND driver. > > > > This patchset applies on-top of "arm64: Simple additions to > > NS2 DT" v1 patchset and is available in ns2_nand_v5 branch of > > https://github.com/Broadcom/arm64-linux.git. > > > > The patchset is tested on NS2 SVK. > > Applied patches 1 and 2. My "Reviewed-by" on patch 3 stands. > Thanks Brian. Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] mtd: brcmnand: factor out CFG and CFG_EXT bitfields
From: Brian Norris
Use enum instead of magic numbers for CFG and CFG_EXT bitfields.
Signed-off-by: Brian Norris
Tested-by: Anup Patel
---
drivers/mtd/nand/brcmnand/brcmnand.c | 38 +---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..dda96fa 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -344,6 +344,28 @@ static const u8 brcmnand_cs_offsets_cs0[] = {
[BRCMNAND_CS_TIMING2] = 0x14,
};
+/*
+ * Bitfields for the CFG and CFG_EXT registers. Pre-v7.1 controllers only had
+ * one config register, but once the bitfields overflowed, newer controllers
+ * (v7.1 and newer) added a CFG_EXT register and shuffled a few fields around.
+ */
+enum {
+ CFG_BLK_ADR_BYTES_SHIFT = 8,
+ CFG_COL_ADR_BYTES_SHIFT = 12,
+ CFG_FUL_ADR_BYTES_SHIFT = 16,
+ CFG_BUS_WIDTH_SHIFT = 23,
+ CFG_BUS_WIDTH = BIT(CFG_BUS_WIDTH_SHIFT),
+ CFG_DEVICE_SIZE_SHIFT = 24,
+
+ /* Only for pre-v7.1 (with no CFG_EXT register) */
+ CFG_PAGE_SIZE_SHIFT = 20,
+ CFG_BLK_SIZE_SHIFT = 28,
+
+ /* Only for v7.1+ (with CFG_EXT register) */
+ CFG_EXT_PAGE_SIZE_SHIFT = 0,
+ CFG_EXT_BLK_SIZE_SHIFT = 4,
+};
+
/* BRCMNAND_INTFC_STATUS */
enum {
INTFC_FLASH_STATUS = GENMASK(7, 0),
@@ -1720,17 +1742,19 @@ static int brcmnand_set_cfg(struct brcmnand_host *host,
}
device_size = fls64(cfg->device_size) - fls64(BRCMNAND_MIN_DEVSIZE);
- tmp = (cfg->blk_adr_bytes << 8) |
- (cfg->col_adr_bytes << 12) |
- (cfg->ful_adr_bytes << 16) |
- (!!(cfg->device_width == 16) << 23) |
- (device_size << 24);
+ tmp = (cfg->blk_adr_bytes << CFG_BLK_ADR_BYTES_SHIFT) |
+ (cfg->col_adr_bytes << CFG_COL_ADR_BYTES_SHIFT) |
+ (cfg->ful_adr_bytes << CFG_FUL_ADR_BYTES_SHIFT) |
+ (!!(cfg->device_width == 16) << CFG_BUS_WIDTH_SHIFT) |
+ (device_size << CFG_DEVICE_SIZE_SHIFT);
if (cfg_offs == cfg_ext_offs) {
- tmp |= (page_size << 20) | (block_size << 28);
+ tmp |= (page_size << CFG_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_offs, tmp);
} else {
nand_writereg(ctrl, cfg_offs, tmp);
- tmp = page_size | (block_size << 4);
+ tmp = (page_size << CFG_EXT_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_EXT_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_ext_offs, tmp);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
This patch also fixes use of node labels in ns2-svk.dts.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Brian Norris
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
- soc: soc {
- i2c0: i2c@6608 {
- status = "ok";
- };
+&i2c0 {
+ status = "ok";
+};
- i2c1: i2c@660b {
- status = "ok";
- };
+&i2c1 {
+ status = "ok";
+};
+
+&uart3 {
+ status = "ok";
+};
- uart3: serial@6613 {
- status = "ok";
- };
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-has-wp;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index dda96fa..b410527 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+ u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1954,6 +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
chip->controller = &ctrl->controller;
+ /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+ cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+ nand_writereg(ctrl, cfg_offs,
+ nand_readreg(ctrl, cfg_offs) & ~CFG_BUS_WIDTH);
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
> -Original Message-
> From: Anup Patel [mailto:anup.pa...@broadcom.com]
> Sent: 30 October 2015 11:49
> To: David Woodhouse; Brian Norris; Linux MTD
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Catalin Marinas; Will Deacon;
> Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui; Scott Branden; Florian
> Fainelli;
> Pramod Kumar; Vikram Prakash; Sandeep Tripathy; Linux ARM Kernel; Device
> Tree; Linux Kernel; bcm-kernel-feedback-list; Anup Patel
> Subject: [PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing
> nand_scan_ident()
>
> Just like other NAND controllers, the NAND READID command only works in 8bit
> mode for all versions of BRCMNAND controller.
>
> This patch forces 8bit mode for each NAND CS in brcmnand_init_cs() before
> doing nand_scan_ident() to ensure that BRCMNAND controller is in 8bit mode
> when NAND READID command is issued.
>
> Signed-off-by: Anup Patel
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> ---
> drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index dda96fa..641591d 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host
> *host)
> struct mtd_info *mtd;
> struct nand_chip *chip;
> int ret;
> + u16 cfg_offs;
> struct mtd_part_parser_data ppdata = { .of_node = dn };
>
> ret = of_property_read_u32(dn, "reg", &host->cs); @@ -1954,6
> +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
>
> chip->controller = &ctrl->controller;
>
> + /*
> + * The bootloader might have configured 16bit mode but
> + * NAND READID command only works in 8bit mode. We force
> + * 8bit mode here to ensure that NAND READID commands works.
> + */
> + cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
> + nand_writereg(ctrl, cfg_offs,
> + nand_readreg(ctrl, cfg_offs) & CFG_BUS_WIDTH);
This should have been "nand_readreg(ctrl, cfg_offs) & ~CFG_BUS_WIDTH".
My bad ...
--
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/3] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v5 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v4: - Fix accidental typo in patch2 regarding use of CFG_BUS_WIDTH Changes since v3: - Include Brian's patch for magic number cleanup related to CFG and CFG_EXT registers - Base patch1 of v3 patchset upon Brian's cleanup patch Changes since v2: - Dropped patch1 and patch2 because these are already merged by MTD maintainer. - Avoid using absolute node paths in ns2-svk.dts. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (2): mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 Brian Norris (1): mtd: brcmnand: factor out CFG and CFG_EXT bitfields arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 +--- arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/brcmnand/brcmnand.c | 48 +++- 3 files changed, 75 insertions(+), 17 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 0/3] NAND support for Broadcom NS2 SoC
Hi All, Please disregard this patchset. There is an accidental typo in patch2. We should use ~CFG_BUS_WIDTH instead of CFG_BUS_WIDTH in patch2. I will quickly send v5 patchset to fix this. Sorry, for the noise. Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/3] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index dda96fa..641591d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1912,6 +1912,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+ u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1954,6 +1955,15 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
chip->controller = &ctrl->controller;
+ /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+ cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+ nand_writereg(ctrl, cfg_offs,
+ nand_readreg(ctrl, cfg_offs) & CFG_BUS_WIDTH);
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/3] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v4 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v3: - Include Brian's patch for magic number cleanup related to CFG and CFG_EXT registers - Base patch1 of v3 patchset upon Brian's cleanup patch Changes since v2: - Dropped patch1 and patch2 because these are already merged by MTD maintainer. - Avoid using absolute node paths in ns2-svk.dts. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (2): mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 Brian Norris (1): mtd: brcmnand: factor out CFG and CFG_EXT bitfields arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 +--- arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/brcmnand/brcmnand.c | 48 +++- 3 files changed, 75 insertions(+), 17 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
This patch also fixes use of node labels in ns2-svk.dts.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Brian Norris
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
- soc: soc {
- i2c0: i2c@6608 {
- status = "ok";
- };
+&i2c0 {
+ status = "ok";
+};
- i2c1: i2c@660b {
- status = "ok";
- };
+&i2c1 {
+ status = "ok";
+};
+
+&uart3 {
+ status = "ok";
+};
- uart3: serial@6613 {
- status = "ok";
- };
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-has-wp;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] mtd: brcmnand: factor out CFG and CFG_EXT bitfields
From: Brian Norris
Use enum instead of magic numbers for CFG and CFG_EXT bitfields.
Signed-off-by: Brian Norris
Tested-by: Anup Patel
---
drivers/mtd/nand/brcmnand/brcmnand.c | 38 +---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..dda96fa 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -344,6 +344,28 @@ static const u8 brcmnand_cs_offsets_cs0[] = {
[BRCMNAND_CS_TIMING2] = 0x14,
};
+/*
+ * Bitfields for the CFG and CFG_EXT registers. Pre-v7.1 controllers only had
+ * one config register, but once the bitfields overflowed, newer controllers
+ * (v7.1 and newer) added a CFG_EXT register and shuffled a few fields around.
+ */
+enum {
+ CFG_BLK_ADR_BYTES_SHIFT = 8,
+ CFG_COL_ADR_BYTES_SHIFT = 12,
+ CFG_FUL_ADR_BYTES_SHIFT = 16,
+ CFG_BUS_WIDTH_SHIFT = 23,
+ CFG_BUS_WIDTH = BIT(CFG_BUS_WIDTH_SHIFT),
+ CFG_DEVICE_SIZE_SHIFT = 24,
+
+ /* Only for pre-v7.1 (with no CFG_EXT register) */
+ CFG_PAGE_SIZE_SHIFT = 20,
+ CFG_BLK_SIZE_SHIFT = 28,
+
+ /* Only for v7.1+ (with CFG_EXT register) */
+ CFG_EXT_PAGE_SIZE_SHIFT = 0,
+ CFG_EXT_BLK_SIZE_SHIFT = 4,
+};
+
/* BRCMNAND_INTFC_STATUS */
enum {
INTFC_FLASH_STATUS = GENMASK(7, 0),
@@ -1720,17 +1742,19 @@ static int brcmnand_set_cfg(struct brcmnand_host *host,
}
device_size = fls64(cfg->device_size) - fls64(BRCMNAND_MIN_DEVSIZE);
- tmp = (cfg->blk_adr_bytes << 8) |
- (cfg->col_adr_bytes << 12) |
- (cfg->ful_adr_bytes << 16) |
- (!!(cfg->device_width == 16) << 23) |
- (device_size << 24);
+ tmp = (cfg->blk_adr_bytes << CFG_BLK_ADR_BYTES_SHIFT) |
+ (cfg->col_adr_bytes << CFG_COL_ADR_BYTES_SHIFT) |
+ (cfg->ful_adr_bytes << CFG_FUL_ADR_BYTES_SHIFT) |
+ (!!(cfg->device_width == 16) << CFG_BUS_WIDTH_SHIFT) |
+ (device_size << CFG_DEVICE_SIZE_SHIFT);
if (cfg_offs == cfg_ext_offs) {
- tmp |= (page_size << 20) | (block_size << 28);
+ tmp |= (page_size << CFG_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_offs, tmp);
} else {
nand_writereg(ctrl, cfg_offs, tmp);
- tmp = page_size | (block_size << 4);
+ tmp = (page_size << CFG_EXT_PAGE_SIZE_SHIFT) |
+ (block_size << CFG_EXT_BLK_SIZE_SHIFT);
nand_writereg(ctrl, cfg_ext_offs, tmp);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/2] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 28 October 2015 05:45
> To: Anup Patel
> Cc: David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark Rutland;
> Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui;
> Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel;
> bcm-kernel-feedback-list
> Subject: Re: [PATCH v3 1/2] mtd: brcmnand: Force 8bit mode before doing
> nand_scan_ident()
>
> On Fri, Oct 23, 2015 at 10:46:12AM +0530, Anup Patel wrote:
> > Just like other NAND controllers, the NAND READID command only works
> > in 8bit mode for all versions of BRCMNAND controller.
> >
> > This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
> > before doing nand_scan_ident() to ensure that BRCMNAND controller is
> > in 8bit mode when NAND READID command is issued.
> >
> > Signed-off-by: Anup Patel
> > Reviewed-by: Ray Jui
> > Reviewed-by: Scott Branden
> > ---
> > drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> > b/drivers/mtd/nand/brcmnand/brcmnand.c
> > index 4cba03d..0be8ef9 100644
> > --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> > @@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host
> *host)
> > struct mtd_info *mtd;
> > struct nand_chip *chip;
> > int ret;
> > + u16 cfg_offs;
> > struct mtd_part_parser_data ppdata = { .of_node = dn };
> >
> > ret = of_property_read_u32(dn, "reg", &host->cs); @@ -1930,6
> > +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
> >
> > chip->controller = &ctrl->controller;
> >
> > + /*
> > +* The bootloader might have configured 16bit mode but
> > +* NAND READID command only works in 8bit mode. We force
> > +* 8bit mode here to ensure that NAND READID commands works.
> > +*/
> > + cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
> > + nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) &
> > +~BIT(23));
>
> Can we get a new enum for cfg bits? Unfortunately, I never managed that in
> brcmnand_set_cfg(); just magic numbers :( But I'd like to stop that if we're
> going
> to have to touch these bits outside of brcmnand_set_cfg().
Even I felt the need to have enum for cfg bits, just like other parts of the
BRCM NAND driver.
>
> > +
> > if (nand_scan_ident(mtd, 1, NULL))
> > return -ENXIO;
> >
>
> How about the following, as a preparatory patch? Only compile tested.
>
> From c5423a86dbfa33b550d2b170bda3c12ecf4d5313 Mon Sep 17 00:00:00
> 2001
> From: Brian Norris
> Date: Tue, 27 Oct 2015 17:12:13 -0700
> Subject: [PATCH] mtd: brcmnand: factor out CFG and CFG_EXT bitfields
>
> These used magic numbers. Shame on me.
>
> Signed-off-by: Brian Norris
> Cc: Anup Patel
> ---
> drivers/mtd/nand/brcmnand/brcmnand.c | 38
> +---
> 1 file changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index d694d876631e..c93fbc3869ee 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -344,6 +344,28 @@ static const u8 brcmnand_cs_offsets_cs0[] = {
> [BRCMNAND_CS_TIMING2] = 0x14,
> };
>
> +/*
> + * Bitfields for the CFG and CFG_EXT registers. Pre-v7.1 controllers
> +only had
> + * one config register, but once the bitfields overflowed, newer
> +controllers
> + * (v7.1 and newer) added a CFG_EXT register and shuffled a few fields
> around.
> + */
> +enum {
> + CFG_BLK_ADR_BYTES_SHIFT = 8,
> + CFG_COL_ADR_BYTES_SHIFT = 12,
> + CFG_FUL_ADR_BYTES_SHIFT = 16,
> + CFG_BUS_WIDTH_SHIFT = 23,
> + CFG_BUS_WIDTH =
> BIT(CFG_BUS_WIDTH_SHIFT),
> + CFG_DEVICE_SIZE_SHIFT = 24,
> +
> + /* Only for pre-v7.1 (with no CFG_EXT register) */
> + CFG_PAGE_SIZE_SHIFT = 20,
> + CFG_BLK_SIZE_SHIFT = 28,
> +
> + /* Only for v7.1+ (with CFG_EXT register) */
> + CFG_EXT_PAGE_SIZE_SHIFT = 0,
> + CFG_EXT_BLK_SIZE_SHIFT = 4,
> +};
> +
> /* BRCMNAND_INTFC_STATUS */
> enum {
> INTFC_FLASH_STATUS = GENMASK(7,
RE: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2
> -Original Message-
> From: Ray Jui [mailto:r...@broadcom.com]
> Sent: 28 October 2015 06:17
> To: Brian Norris
> Cc: Anup Patel; David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark
> Rutland; Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala;
> Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel;
> bcm-kernel-feedback-list
> Subject: Re: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for
> NS2
>
>
>
> On 10/27/2015 5:39 PM, Brian Norris wrote:
> > On Tue, Oct 27, 2015 at 05:25:32PM -0700, Ray Jui wrote:
> >> On 10/27/2015 5:19 PM, Brian Norris wrote:
> >>> On Fri, Oct 23, 2015 at 10:46:13AM +0530, Anup Patel wrote:
> >>>> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
> >>>> b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> >>>> index f603277..9610822 100644
> >>>> --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
> >>>> +++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
> >>>> @@ -212,5 +212,19 @@
> >>>> compatible = "brcm,iproc-rng200";
> >>>> reg = <0x6622 0x28>;
> >>>> };
> >>>> +
> >>>> +nand: nand@6646 {
> >>>> +compatible = "brcm,nand-iproc", "brcm,brcmnand-
> v6.1";
> >>>
> >>> Technically, the binding says you should also have "brcm,brcmnand"
> >>> as a last resort. Otherwise (for the NAND parts):
> >>>
> >>
> >> I believe Anup was seeing issues when both "brcm,nand-iproc" and
> >> "brcm,brcmnand" are present.
> >>
> >> Note "brcm,nand-iproc" invokes 'iproc_nand_probe', which calls
> >> 'brcmnand_probe' in the end.
> >>
> >> "brcm,brcmnand" invokes 'brcmstb_nand_probe', which also calls
> >> 'brcmstb_probe', but without all the prep configuration required for
> >> "brcm,nand-iproc".
> >
> > Ah, I forgot about that problem. That seems like an OF infrastructure
> > issue that could be fixed. We could lump these drivers back together,
> > and make sure that "brcm,nand-iproc" gets the priority in the
> > of_device_id list.
> >
> > Or we could just relax the DT binding.
> >
> > But wait, wouldn't cygnus already have that problem? You're using the
> > binding I suggested in arch/arm/boot/dts/bcm-cygnus.dtsi.
>
> Interestingly, we do not see this problem with Cygnus or NSP, but only on NS2
> (arm64 based). There may be a difference between how OF devices are
> instantiated between arm and arm64?
Alternately, it could be also about order in-which platform drivers are matched
for newly created OF device.
>
> >
> > Oh, and I see we hacked this one in drivers/mtd/nand/brcmnand/Makefile:
> >
> ># link order matters; don't link the more generic brcmstb_nand.o before
> > the
> ># more specific iproc_nand.o, for instance
>
> Yes, I see that too (after sending out my previous email, :)). Maybe
> Anup can help to elaborate on the problem. I'm now getting a bit
> confused on how the problem can surface on NS2.
I think for a newly created OF devices the Linux device driver framework will
match the platform drivers in the order in which they are registered by module
init functions. Now the order of module init function calls will be based how
the .initcall section is formed by linker and order in which objects are linked.
IMHO, if multiple platform drivers match given OF device then platform driver
with longest matching compatible string should only be probed. I don't know
how big change this would be for OF framework.
>
> But in general, I think it's a good idea to relax the requirement in the
> DT binding document to not require "brcm,brcmnand", in the case when
> "brcm,nand-iproc" and "brcm,nand-bcm63138" are present.
Even I think, it will be good to relax the DT bindings requirement for
BRCM NAND driver.
Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/6] arm64: Simple additions to NS2 DT
Ping ??? Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..0be8ef9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+ u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1930,6 +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
chip->controller = &ctrl->controller;
+ /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+ cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+ nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) & ~BIT(23));
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
This patch also fixes use of node labels in ns2-svk.dts.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
- soc: soc {
- i2c0: i2c@6608 {
- status = "ok";
- };
+&i2c0 {
+ status = "ok";
+};
- i2c1: i2c@660b {
- status = "ok";
- };
+&i2c1 {
+ status = "ok";
+};
+
+&uart3 {
+ status = "ok";
+};
- uart3: serial@6613 {
- status = "ok";
- };
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-has-wp;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v3 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v2: - Dropped patch1 and patch2 because these are already merged by MTD maintainer. - Avoid using absolute node paths in ns2-svk.dts. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (2): mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 -- arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/brcmnand/brcmnand.c | 9 + 3 files changed, 43 insertions(+), 10 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for NS2
> -Original Message-
> From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
> Sent: 20 October 2015 14:36
> To: Anup Patel
> Cc: David Woodhouse; Brian Norris; linux-...@lists.infradead.org; Sudeep
> Holla; Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala;
> Catalin
> Marinas; Will Deacon; Ray Jui; Scott Branden; Florian Fainelli; Pramod Kumar;
> Vikram Prakash; Sandeep Tripathy; linux-arm-ker...@lists.infradead.org;
> devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; bcm-kernel-
> feedback-list
> Subject: Re: [PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for
> NS2
>
>
>
> On 16/10/15 10:08, Anup Patel wrote:
> > The NAND controller on NS2 SoC is compatible with existing BRCM IPROC
> > NAND driver so let's enable it in NS2 DT and
> > NS2 SVK DT.
> >
> > Signed-off-by: Anup Patel
> > Reviewed-by: Ray Jui
> > Reviewed-by: Scott Branden
> > ---
> > arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12
> > arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > index e5950d5..a754160 100644
> > --- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > +++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
> > @@ -63,5 +63,17 @@
> > uart3: serial@6613 {
> > status = "ok";
> > };
>
> Better to change even the above reference, see below.
>
> > +
> > + nand: nand@6646 {
>
> In most of the cases where such static overlays are done, I have seen the
> labels
> being used to refer back the node. Using the complete node name again is kind
> of inviting trouble as even minor typo results in creation of another node.
Thanks for pointing. I will use label here for both uart3 and nand.
Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
> -Original Message- > From: Ray Jui [mailto:r...@broadcom.com] > Sent: 16 October 2015 21:06 > To: Anup Patel; David Woodhouse; Brian Norris; linux-...@lists.infradead.org > Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin > Marinas; Will Deacon; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram > Prakash; Sandeep Tripathy; linux-arm-ker...@lists.infradead.org; > devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; bcm-kernel- > feedback-list > Subject: Re: [PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in > brcmnand_write() > > Correct me if I remember it wrong, but I thought this patch has already been > merged by Brian? Yes, patch1 and patch2 were merged by Brian. I realized this after I had send-out v2. Anyways we can ignore patch1 and patch2 from this patchset because they are same as v1. Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
We should always type-cast pointer to "long" or "unsigned long"
because size of pointer is same as machine word size. This will
avoid pointer type-cast issues on both 32bit and 64bit systems.
This patch fixes pointer type-cast issue in brcmnand_write()
as-per above info.
Signed-off-by: Anup Patel
Reviewed-by: Vikram Prakash
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index fddb795..4cba03d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1544,9 +1544,9 @@ static int brcmnand_write(struct mtd_info *mtd, struct
nand_chip *chip,
dev_dbg(ctrl->dev, "write %llx <- %p\n", (unsigned long long)addr, buf);
- if (unlikely((u32)buf & 0x03)) {
+ if (unlikely((unsigned long)buf & 0x03)) {
dev_warn(ctrl->dev, "unaligned buffer: %p\n", buf);
- buf = (u32 *)((u32)buf & ~0x03);
+ buf = (u32 *)((unsigned long)buf & ~0x03);
}
brcmnand_wp(mtd, 0);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..0be8ef9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+ u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", &host->cs);
@@ -1930,6 +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
chip->controller = &ctrl->controller;
+ /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+ cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+ nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) & ~BIT(23));
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v2 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (4): mtd: brcmnand: Fix pointer type-cast in brcmnand_write() mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64 mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/Kconfig | 2 +- drivers/mtd/nand/brcmnand/brcmnand.c | 13 +++-- 4 files changed, 38 insertions(+), 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12
arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
2 files changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..a754160 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -63,5 +63,17 @@
uart3: serial@6613 {
status = "ok";
};
+
+ nand: nand@6646 {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-has-wp;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
The BRCM NAND driver can be re-used for Broadcom ARM64 SoCs hence this patch updates Kconfig to allow selection of MTD_NAND_BRCMNAND for ARM64. Signed-off-by: Anup Patel Reviewed-by: Vikram Prakash Reviewed-by: Ray Jui Reviewed-by: Pramod KUMAR Reviewed-by: Scott Branden --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 3324281..a1b5819 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND config MTD_NAND_BRCMNAND tristate "Broadcom STB NAND controller" - depends on ARM || MIPS + depends on ARM || ARM64 || MIPS help Enables the Broadcom NAND controller driver. The controller was originally designed for Set-Top Box but is used on various BCM7xxx, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller
Hi Brian, > -Original Message- > From: Brian Norris [mailto:computersforpe...@gmail.com] > Sent: 13 October 2015 02:58 > To: Anup Patel > Cc: Florian Fainelli; Scott Branden; linux-arm-ker...@lists.infradead.org; Rob > Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; > Will Deacon; David Woodhouse; Ray Jui; Pramod Kumar; Vikram Prakash; > Sandeep Tripathy; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; > linux-...@lists.infradead.org; bcm-kernel-feedback-list; Rafal Milecki > Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND > controller > > Hi Anup, > > On Wed, Oct 07, 2015 at 03:33:50AM +, Anup Patel wrote: > > > -Original Message- > > > From: Florian Fainelli [mailto:f.faine...@gmail.com] > > > > > > On 06/10/15 15:25, Scott Branden wrote: > > > > > > Then instead of adding a "reset flag" to Device Tree, another > > > approach could be to put the desired or currently configured > > > exhaustive list of NAND timings in Device Tree, and based on that you > > > could > have this: > > > > > > - the NAND controller driver finds that these timings match the > > > current configuration, you are good to go > > > > > > - the NAND controller drivers finds a difference in how current > > > timings are configured vs. desired timings, and issues a controller > > > reset, prior to applying new timing configuration > > > > To add to this ... > > > > The mechanism to reset is BRCM NAND controller is SOC specific so the > > SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how > > to reset the NAND controller. > > > > For iProc SoC family, the NAND controller reset is through IDM > > register space which is only iomap'ed by iproc_nand.c. > > > > We might end-up having one more SoC specific callback which will be > > Provided by iproc_nand.c to brcmnand.c. > > > > > > > > - no timings are configured, reset the controller and use existing > > > auto-detection capabilities like ONFI modes > > > > > > Typically you would put the desired timings instead of the currently > > > configured timings though.. > > > > Overall, it would good to support timing parameters through DT or ONFI > > but for now have we can rely on reset and auto-devid configuration. > > I don't want to support a DT property that is only used as a workaround for > the > right solution. That means the property may quickly become obsolete, yet we > have to support it forever. > > > > > >> compatible = "brcm,iproc-nand-ns2", ...; > > > >> > > > > As described above - the option is not SoC specific. It is system > > > > specific. In some systems we may wish to reset the NAND > > > > controller in linux. In some we may wish to rely on > > > > initialization that has already been done to speed up boot times. > > > > > > It seems to me like having this property is fine as long as you are > > > describing that the controller *needs* a reset to operate properly, > > > it does not strike me as a particularly well suited property if its > > > side effect and main usage is to keep or wipe-out existing NAND timings. > > > > IMHO, having SoC specific compatible string for NS2 is like saying > > NAND controller on NS2 is different from other iProc SoCs whereas > > Having optional DT flags for quirks/work-arounds (e.g. NAND controller > > reset) is like saying NAND controller on NS2 same as other iProc SoCs > > but some additional programming is required. > > OK... so what is the reason that you have to reset the controller on NS2 and > not > Cygnus? Is it a SoC difference (i.e., compatible string)? > Firmware/bootloader difference? So far, all statements have been non-specific, > AFAICT. > On NS2 SVK, we have 16bit NAND chip whereas on all Cygnus SVKs we mostly have 8bit NAND chip. The bootloader on NS2 touches NAND controller and configures it to 16bit mode. When we reach BRCMNAND driver probing on NS2, the BRCMNAND controller is already in 16bit mode so NAND READID command does not work. On Cygnus, we mostly have 8bit NAND chip so BRCMNAND controller is always in 8bit mode so we don't see any issue with NAND READID command. We really don't require to reset BRCNNAND controller on NS2 to get NAND READID command working. Instead, we can simply force 8bit mode before we do nand_scan_ident() for each CS. This will be a much simpler fix for all versions of BRCMNAND because NAND READID command will only work in 8bit mode irrespective to BRCMNAND version (NAND controllers from other vendors might also have similar issue with NAND READID command). I will send a revised patchset which will fix brcmnand_init_cs() as-per above. Best Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller
> -Original Message- > From: Florian Fainelli [mailto:f.faine...@gmail.com] > Sent: 07 October 2015 04:51 > To: Scott Branden; Brian Norris; Anup Patel > Cc: linux-arm-ker...@lists.infradead.org; Rob Herring; Pawel Moll; Mark > Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; Will Deacon; David > Woodhouse; Ray Jui; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep > Tripathy; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux- > m...@lists.infradead.org; bcm-kernel-feedback-list; Rafal Milecki > Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND > controller > > On 06/10/15 15:25, Scott Branden wrote: > > Hi Brian, > > > > On 15-10-06 06:41 AM, Brian Norris wrote: > > > >>>> > >>>> Is there a reason not to do this reset unconditionally? I recall > >>>> this came up in discussion previously, when the OpenWRT folks were > >>>> trying to integrate with BCMA, where this reset was one of the few > >>>> differences between the > >>>> platform- > >>>> device-based driver (i.e., this one) and the BCMA based driver. > >>>> Might it help > >>>> simplify things a bit if we just did the same thing everywhere? > >>> > >>> This driver is currently shared by Cygnus and NS2. > >>> > >>> We had similar suggestion when this patch was reviewed internally in > >>> Broadcom. > >>> > >>> The rationale for adding optional DT flag is as follows: > >>> 1. The NAND controller reset is currently required for NS2 only so > >>> that it is in sane state before any NAND commands are issued. We are > >>> not sure if Cygnus and all future iProc SoCs will require NAND > >>> controller reset. > >> > >> I'm not sure this is a very strong reason. It seems fairly reasonable > >> in general to reset a HW block before using it. > > > > Efficient Boot time is a very strong reason for needing this actually. > > We use the NAND controller in the bootROM, boot1/BL1, u-boot/UEFI, and > > then Kernel stage. By properly initializing the controller once we do > > not need to reset it 4 different times. > > This could be used as a reverse argument, issuing a reset will increase the > boot > time. > > > > >> > >>> 2. The NAND controller reset in probe would certainly increase Linux > >>> boot time so for certain iProc SoCs we might choose avoid NAND > >>> controller reset to reduce boot time if possible. > >> > >> I recall this reason being mentioned before. I believe this only > >> happens because the brcmnand driver doesn't yet handle configuring > >> the timing registers, so iProc is implicitly relying on the > >> bootloader to configure the NAND timings. Perhaps it's time that we > >> fix that. I'd rather not add extra DT properties unless we actually > >> need to [1]. And having proper timing configuration in the Linux > >> driver will help improve speeds for all users (whose timings may not be > configured in the bootloader). > > > > This is the very reason we need the optional reset property. We need > > to have timings configured by the linux driver or not. Yes, in some > > cases we will be relying on earlier boot stages to configure some of > > the hardware. > > Then instead of adding a "reset flag" to Device Tree, another approach could > be > to put the desired or currently configured exhaustive list of NAND timings in > Device Tree, and based on that you could have this: > > - the NAND controller driver finds that these timings match the current > configuration, you are good to go > > - the NAND controller drivers finds a difference in how current timings are > configured vs. desired timings, and issues a controller reset, prior to > applying > new timing configuration To add to this ... The mechanism to reset is BRCM NAND controller is SOC specific so the SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how to reset the NAND controller. For iProc SoC family, the NAND controller reset is through IDM register space which is only iomap'ed by iproc_nand.c. We might end-up having one more SoC specific callback which will be Provided by iproc_nand.c to brcmnand.c. > > - no timings are configured, reset the controller and use existing > auto-detection > capabilities like ONFI modes > > Typically you would put the desired timings instead of the currently > configured > timings though.. Overall, it would go
RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 05 October 2015 03:20
> To: Anup Patel
> Cc: linux-arm-ker...@lists.infradead.org; Rob Herring; Pawel Moll; Mark
> Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; Will Deacon; David
> Woodhouse; Ray Jui; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram
> Prakash; Sandeep Tripathy; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org; bcm-kernel-feedback-
> list; Rafal Milecki
> Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
> controller
>
> + Rafal (to extend this mighty CC list)
>
> On Fri, Oct 02, 2015 at 11:26:44PM +0530, Anup Patel wrote:
> > The BRCM NAND controller on NS2 SoC requires a reset to cleanup
> > previously configured NAND controller state.
> >
> > This patch adds optional boolean device tree flag named
> > "brcm,nand-iproc-reset". If this flag is present in NAND controller DT
> > node then BRCM IPROC NAND driver will reset the NAND controller before
> > any commands are issued.
>
> Is there a reason not to do this reset unconditionally? I recall this came up
> in
> discussion previously, when the OpenWRT folks were trying to integrate with
> BCMA, where this reset was one of the few differences between the platform-
> device-based driver (i.e., this one) and the BCMA based driver. Might it help
> simplify things a bit if we just did the same thing everywhere?
This driver is currently shared by Cygnus and NS2.
We had similar suggestion when this patch was reviewed
internally in Broadcom.
The rationale for adding optional DT flag is as follows:
1. The NAND controller reset is currently required for NS2 only so
that it is in sane state before any NAND commands are issued. We
are not sure if Cygnus and all future iProc SoCs will require NAND
controller reset.
2. The NAND controller reset in probe would certainly increase
Linux boot time so for certain iProc SoCs we might choose avoid
NAND controller reset to reduce boot time if possible.
Regards
Anup
>
> Brian
>
> > Signed-off-by: Anup Patel
> > Reviewed-by: Pramod KUMAR
> > Reviewed-by: Ray Jui
> > Reviewed-by: Scott Branden
> > ---
> > drivers/mtd/nand/brcmnand/iproc_nand.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/brcmnand/iproc_nand.c
> > b/drivers/mtd/nand/brcmnand/iproc_nand.c
> > index 683495c..d837207 100644
> > --- a/drivers/mtd/nand/brcmnand/iproc_nand.c
> > +++ b/drivers/mtd/nand/brcmnand/iproc_nand.c
> > @@ -11,6 +11,7 @@
> > * GNU General Public License for more details.
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -35,6 +36,10 @@ struct iproc_nand_soc_priv {
> > #define IPROC_NAND_APB_LE_MODE BIT(24)
> > #define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
> >
> > +#define IPROC_NAND_RESET_OFFSET0x3f8
> > +#define IPROC_NAND_RESET_BIT_SHIFT 0
> > +#define IPROC_NAND_RESET_BIT
> BIT(IPROC_NAND_RESET_BIT_SHIFT)
> > +
> > static bool iproc_nand_intc_ack(struct brcmnand_soc *soc) {
> > struct iproc_nand_soc_priv *priv = soc->priv; @@ -93,6 +98,7 @@
> > static void iproc_nand_apb_access(struct brcmnand_soc *soc, bool
> > prepare)
> >
> > static int iproc_nand_probe(struct platform_device *pdev) {
> > + u32 reset;
> > struct device *dev = &pdev->dev;
> > struct iproc_nand_soc_priv *priv;
> > struct brcmnand_soc *soc;
> > @@ -124,6 +130,19 @@ static int iproc_nand_probe(struct platform_device
> *pdev)
> > soc->ctlrdy_set_enabled = iproc_nand_intc_set;
> > soc->prepare_data_bus = iproc_nand_apb_access;
> >
> > + if (of_property_read_bool(dev->of_node, "brcm,nand-iproc-reset")) {
> > + /* Put controller in reset and wait 10 usecs */
> > + reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > + reset |= IPROC_NAND_RESET_BIT;
> > + writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > + udelay(10);
> > + /* Bring controller out of reset and wait 10 usecs */
> > + reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > + reset &= ~IPROC_NAND_RESET_BIT;
> > + writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > + udelay(10);
> > + }
> > +
> > return brcmnand_probe(pdev, soc);
> > }
> >
> > --
> > 1.9.1
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] mtd: brcmnand: Fix pointer type-cast in brcmnand_write()
We should always type-cast pointer to "long" or "unsigned long"
because size of pointer is same as machine word size. This will
avoid pointer type-cast issues on both 32bit and 64bit systems.
This patch fixes pointer type-cast issue in brcmnand_write()
as-per above info.
Signed-off-by: Anup Patel
Reviewed-by: Vikram Prakash
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index fddb795..4cba03d 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1544,9 +1544,9 @@ static int brcmnand_write(struct mtd_info *mtd, struct
nand_chip *chip,
dev_dbg(ctrl->dev, "write %llx <- %p\n", (unsigned long long)addr, buf);
- if (unlikely((u32)buf & 0x03)) {
+ if (unlikely((unsigned long)buf & 0x03)) {
dev_warn(ctrl->dev, "unaligned buffer: %p\n", buf);
- buf = (u32 *)((u32)buf & ~0x03);
+ buf = (u32 *)((unsigned long)buf & ~0x03);
}
brcmnand_wp(mtd, 0);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" patchset and is available in ns2_nand_v1 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Anup Patel (5): mtd: brcmnand: Fix pointer type-cast in brcmnand_write() mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64 mtd: brcmnand: Optional DT flag to reset IPROC NAND controller Documentation: dt-bindings: Add info about brcm,nand-iproc-reset DT flag arm64: dts: Add BRCM IPROC NAND DT node for NS2 .../devicetree/bindings/mtd/brcm,brcmnand.txt | 4 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12 arch/arm64/boot/dts/broadcom/ns2.dtsi | 15 +++ drivers/mtd/nand/Kconfig | 2 +- drivers/mtd/nand/brcmnand/brcmnand.c | 4 ++-- drivers/mtd/nand/brcmnand/iproc_nand.c| 19 +++ 6 files changed, 53 insertions(+), 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] Documentation: dt-bindings: Add info about brcm,nand-iproc-reset DT flag
This patch updates the BRCM NAND controller DT bindings documentation to add info about newly added optional flag "brcm,nand-iproc-reset". Signed-off-by: Anup Patel Reviewed-by: Pramod KUMAR Reviewed-by: Ray Jui Reviewed-by: Scott Branden --- Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt index 4ff7128..19b7a3c 100644 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt @@ -78,6 +78,10 @@ we define additional 'compatible' properties and associated register resources w for interrupt status/ack. - reg-names: (required) a list of the names corresponding to the previous register ranges. Should contain "iproc-idm" and "iproc-ext". + - brcm,nand-iproc-reset: (optional) Some of the Broadcom IPROC SoCs + require NAND controller to be resetted for cleanup of previously + configured NAND controller state. This optional flag resets the + NAND controller once before any NAND commands are issued. * NAND chip-select -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller
The BRCM NAND controller on NS2 SoC requires a reset to
cleanup previously configured NAND controller state.
This patch adds optional boolean device tree flag named
"brcm,nand-iproc-reset". If this flag is present in NAND
controller DT node then BRCM IPROC NAND driver will reset
the NAND controller before any commands are issued.
Signed-off-by: Anup Patel
Reviewed-by: Pramod KUMAR
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/iproc_nand.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/iproc_nand.c
b/drivers/mtd/nand/brcmnand/iproc_nand.c
index 683495c..d837207 100644
--- a/drivers/mtd/nand/brcmnand/iproc_nand.c
+++ b/drivers/mtd/nand/brcmnand/iproc_nand.c
@@ -11,6 +11,7 @@
* GNU General Public License for more details.
*/
+#include
#include
#include
#include
@@ -35,6 +36,10 @@ struct iproc_nand_soc_priv {
#define IPROC_NAND_APB_LE_MODE BIT(24)
#define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
+#define IPROC_NAND_RESET_OFFSET0x3f8
+#define IPROC_NAND_RESET_BIT_SHIFT 0
+#define IPROC_NAND_RESET_BIT BIT(IPROC_NAND_RESET_BIT_SHIFT)
+
static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)
{
struct iproc_nand_soc_priv *priv = soc->priv;
@@ -93,6 +98,7 @@ static void iproc_nand_apb_access(struct brcmnand_soc *soc,
bool prepare)
static int iproc_nand_probe(struct platform_device *pdev)
{
+ u32 reset;
struct device *dev = &pdev->dev;
struct iproc_nand_soc_priv *priv;
struct brcmnand_soc *soc;
@@ -124,6 +130,19 @@ static int iproc_nand_probe(struct platform_device *pdev)
soc->ctlrdy_set_enabled = iproc_nand_intc_set;
soc->prepare_data_bus = iproc_nand_apb_access;
+ if (of_property_read_bool(dev->of_node, "brcm,nand-iproc-reset")) {
+ /* Put controller in reset and wait 10 usecs */
+ reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
+ reset |= IPROC_NAND_RESET_BIT;
+ writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
+ udelay(10);
+ /* Bring controller out of reset and wait 10 usecs */
+ reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
+ reset &= ~IPROC_NAND_RESET_BIT;
+ writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
+ udelay(10);
+ }
+
return brcmnand_probe(pdev, soc);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] mtd: nand: Allow MTD_NAND_BRCMNAND to be selected for ARM64
The BRCM NAND driver can be re-used for Broadcom ARM64 SoCs hence this patch updates Kconfig to allow selection of MTD_NAND_BRCMNAND for ARM64. Signed-off-by: Anup Patel Reviewed-by: Vikram Prakash Reviewed-by: Ray Jui Reviewed-by: Pramod KUMAR Reviewed-by: Scott Branden --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 3324281..a1b5819 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -393,7 +393,7 @@ config MTD_NAND_GPMI_NAND config MTD_NAND_BRCMNAND tristate "Broadcom STB NAND controller" - depends on ARM || MIPS + depends on ARM || ARM64 || MIPS help Enables the Broadcom NAND controller driver. The controller was originally designed for Set-Top Box but is used on various BCM7xxx, -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 12
arch/arm64/boot/dts/broadcom/ns2.dtsi| 15 +++
2 files changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..a754160 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -63,5 +63,17 @@
uart3: serial@6613 {
status = "ok";
};
+
+ nand: nand@6646 {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..55c3c5a 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,20 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-iproc-reset;
+ brcm,nand-has-wp;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] arm64: Simple additions to NS2 DT
We add l2-cache, SMMU, reboot, PMUv3, RNG, and I2C DT nodes for NS2 SVK. This patchset is based on v4.3-rc3 and available in ns2_dt1_v1 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Anup Patel (5): arm64: dts: Add L2-cache DT node for NS2 arm64: dts: Add SMMU DT node for NS2 arm64: dts: Add syscon based reboot in DT for NS2 arm64: dts: Add ARM PMUv3 DT node in NS2 DT arm64: dts: Add IPROC RNG200 DT node for NS2 Ray Jui (1): arm64: dts: Add I2C nodes for NS2 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 8 +++ arch/arm64/boot/dts/broadcom/ns2.dtsi| 106 +-- 2 files changed, 110 insertions(+), 4 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] arm64: dts: Add SMMU DT node for NS2
The SMMU-500 driver is already available in Linux kernel. Let's
enable it for NS2 in DT.
This patch keeps mmu-masters attribute empty so that driver patches
can later extend this attribute when adding device DT nodes.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f759175..c5d90e4 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -103,6 +103,47 @@
#size-cells = <1>;
ranges = <0 0 0 0x>;
+ smmu: mmu@6400 {
+ compatible = "arm,mmu-500";
+ reg = <0x6400 0x4>;
+ #global-interrupts = <2>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ mmu-masters;
+ };
+
gic: interrupt-controller@6521 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] arm64: dts: Add syscon based reboot in DT for NS2
To reset NS2, we simply have to write '0' to BIT[1] at offset 0x90
of CRMU space.
The above can be easily achieved by writing 0xfffd at offset 0x90
using syscon-reboot driver. We don't need to have separate driver for
rebooting NS2.
This patch enables syscon-reboot driver for NS2 using DT.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index c5d90e4..5d2ac6b 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -144,6 +144,18 @@
mmu-masters;
};
+ crmu: crmu@65024000 {
+ compatible = "syscon";
+ reg = <0x65024000 0x100>;
+ };
+
+ reboot@65024000 {
+ compatible ="syscon-reboot";
+ regmap = <&crmu>;
+ offset = <0x90>;
+ mask = <0xfffd>;
+ };
+
gic: interrupt-controller@6521 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] arm64: dts: Add IPROC RNG200 DT node for NS2
We have IPROC RNG200 hardware random number generation in
NS2 SoC, lets enable it for NS2 in NS2 DT.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Pramod KUMAR
Reviewed-by: Vikram Prakash
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index bc31c0e..92ecf1c 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -187,5 +187,10 @@
clock-frequency = <23961600>;
status = "disabled";
};
+
+ hwrng: hwrng@6622 {
+ compatible = "brcm,iproc-rng200";
+ reg = <0x6622 0x28>;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] arm64: dts: Add ARM PMUv3 DT node in NS2 DT
The NS2 SoC has Cortex-A57 CPUs which support ARM PMUv3 so,
lets enable ARM PMUv3 in NS2 DT.
Signed-off-by: Anup Patel
Reviewed-by: Vikram Prakash
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 5d2ac6b..bc31c0e 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -44,7 +44,7 @@
#address-cells = <2>;
#size-cells = <0>;
- cpu@0 {
+ A57_0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 0>;
@@ -53,7 +53,7 @@
next-level-cache = <&CLUSTER0_L2>;
};
- cpu@1 {
+ A57_1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 1>;
@@ -62,7 +62,7 @@
next-level-cache = <&CLUSTER0_L2>;
};
- cpu@2 {
+ A57_2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 2>;
@@ -71,7 +71,7 @@
next-level-cache = <&CLUSTER0_L2>;
};
- cpu@3 {
+ A57_3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0 3>;
@@ -97,6 +97,18 @@
IRQ_TYPE_EDGE_RISING)>;
};
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <&A57_0>,
+<&A57_1>,
+<&A57_2>,
+<&A57_3>;
+ };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] arm64: dts: Add I2C nodes for NS2
From: Ray Jui
This patch adds iProc I2C DT nodes for NS2 and enable them for the NS2
SVK board
Signed-off-by: Ray Jui
Reviewed-by: Vikram Prakash
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 8
arch/arm64/boot/dts/broadcom/ns2.dtsi| 20
2 files changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 244baf8..e5950d5 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -52,6 +52,14 @@
};
soc: soc {
+ i2c0: i2c@6608 {
+ status = "ok";
+ };
+
+ i2c1: i2c@660b {
+ status = "ok";
+ };
+
uart3: serial@6613 {
status = "ok";
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 92ecf1c..f603277 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -178,6 +178,26 @@
<0x6526 0x1000>;
};
+ i2c0: i2c@6608 {
+ compatible = "brcm,iproc-i2c";
+ reg = <0x6608 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@660b {
+ compatible = "brcm,iproc-i2c";
+ reg = <0x660b 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = ;
+ clock-frequency = <10>;
+ status = "disabled";
+ };
+
uart3: serial@6613 {
compatible = "snps,dw-apb-uart";
reg = <0x6613 0x100>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] arm64: dts: Add L2-cache DT node for NS2
Recent kernels requires cache hierrachy to be defined via DT hence
this patch updates NS2 DT accordingly.
Signed-off-by: Anup Patel
Reviewed-by: Sandeep Tripathy
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 3c92d92..f759175 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -50,6 +50,7 @@
reg = <0 0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+ next-level-cache = <&CLUSTER0_L2>;
};
cpu@1 {
@@ -58,6 +59,7 @@
reg = <0 1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+ next-level-cache = <&CLUSTER0_L2>;
};
cpu@2 {
@@ -66,6 +68,7 @@
reg = <0 2>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+ next-level-cache = <&CLUSTER0_L2>;
};
cpu@3 {
@@ -74,6 +77,11 @@
reg = <0 3>;
enable-method = "spin-table";
cpu-release-addr = <0 0x84b0>;
+ next-level-cache = <&CLUSTER0_L2>;
+ };
+
+ CLUSTER0_L2: l2-cache@000 {
+ compatible = "cache";
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver
On Thu, Nov 13, 2014 at 1:15 PM, Ankit Jindal wrote:
> This patch adds device tree binding documentation for
> X-Gene QMTM UIO driver.
>
> Signed-off-by: Ankit Jindal
> Signed-off-by: Tushar Jagad
> ---
> .../devicetree/bindings/uio/uio_xgene_qmtm.txt | 51
>
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
>
> diff --git a/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
> b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
> new file mode 100644
> index 000..ed85bc6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/uio/uio_xgene_qmtm.txt
> @@ -0,0 +1,51 @@
> +APM X-Gene QMTM nodes
> +
> +The Applied Micro X-Gene SOC has on-chip QMTM (Queue manager
> +and Traffic manager). It is a device for managing hardware queues.
> +It also implements QoS among hardware queues hence term "traffic"
> +manager is present in its name.
> +
> +Required properties:
> +- compatible: Should be "apm,xgene-qmtm"
> +- reg: Address and length of the register set for the device. It contains the
> + information of registers in the same order as described by reg-names.
> +- reg-names: Should contain the register set names
> + - "csr": QMTM control and status register address space.
> + - "fabric": QMTM memory mapped access to queue states.
> +- qpool-memory: Points to the phandle of the node defining memory location
> for
> +creating QMTM queues. This must point to the reserved-memory node
> +(as-per reserved memory bindings). It is expected that size and
> +location of qpool memory will be configurable via bootloader.
> +- clocks: Reference to the clock entry.
> +- num-queues: Number of queues under this QMTM device.
> +- devid: QMTM identification number for the system having multiple QMTM
> devices.
> +This is used to form a unique id (a tuple of queue number and
> +device id) for the queues belonging to this device.
> +
> +Example:
> + qmtm1_uio_qpool: qmtm1_uio_qpool {
> + reg = <0x0 0x0 0x0 0x0>
> + };
> +
> + qmtm1clk: qmtmclk@1f20c000 {
> + compatible = "apm,xgene-device-clock";
> + clock-output-names = "qmtm1clk";
> + status = "ok";
> + };
> +
> + qmtm1_uio: qmtm_uio@1f20 {
> + compatible = "apm,xgene-qmtm";
> + status = "disabled";
> + reg = <0x0 0x1f20 0x0 0x1>,
> + <0x0 0x1b00 0x0 0x40>;
> + reg-names = "csr", "fabric";
> + qpool = <&qmtm1_uio_qpool>;
Small typo, this should be qpool-memory = <...>;
> + clocks = <&qmtm1clk 0>;
> + num-queues = <0x400>;
> + devid = <1>;
> + };
> +
> + /* Board-specific peripheral configurations */
> + &qmtm1_uio {
> + status = "ok";
> + };
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH Resend 0/2] arm64: Add PMU node for APM X-Gene Storm SoC
On 12 August 2014 05:17, Feng Kan wrote: > This patch series adds PMU node for APM X-Gene's Potenza CPU. > Potenza CPU PMU is compatible with ARMv8-PMUv3. > > I have remove the previous notice regarding the dependancy on the GIC driver > from the commit message. > > Feng Kan (1): > dt-bindings: Add Potenza PMU binding > > Vinayak Kale (1): > arm64: dts: Add PMU node for APM X-Gene Storm SOC > > Documentation/devicetree/bindings/arm/pmu.txt | 1 + > arch/arm64/boot/dts/apm-storm.dtsi| 5 + > 2 files changed, 6 insertions(+) > > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Hi Feng, Please follow proper protocol when resending patchset originally authored by someone else. (http://comments.gmane.org/gmane.linux.ports.arm.kernel/310795) Also, I see that original patchset clearly states that second patch depends on a GIC patch [1] authored by you: [1]- https://lkml.org/lkml/2014/2/27/605 (irqchip:gic: change access of gicc_ctrl register to read modify write) I have recently posted RFC patch for PMU support in KVM ARM64 which also requires your GIC patch for APM X-Gene. Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: Support for platforms with split GIC cpu interface registers.
On 22 November 2013 12:34, Anup Patel wrote: > On Fri, Nov 22, 2013 at 12:24 PM, Anup Patel wrote: >> On Fri, Nov 1, 2013 at 3:43 PM, Ian Campbell wrote: >>> At least one platform (APM Storm) places the two pages of the GIC cpu >>> interface >>> (and the vcpu side) at non-contiguous locations. Document two additional >>> regions to cover this split and update the corresponding dtsi. Note that >>> Linux >>> (including KVM) does not use any registers in the second page so there is no >>> associated code change here. Xen will use these new regions, although I've >>> not >>> written the corresponding code yet. >>> >>> The ordering of these new regs is slightly counter intuitive but is inteded >>> to >>> be backward compatible. It is also assumed that all such systems will >>> implement >>> the GIC virtualisation extensions. >>> >>> Add comments to all of the reg examples to help clarify what is going on. >> >> Adding Catalin, Marc Z, and Will D. >> >> I looked up the GIC-400 TRM (more specifically page 33 of >> DDI0471B_gic400_r0p1_trm.pdf) but could not find any info >> on additional page for CPU interface. >> >> Am I looking at the wrong doc? > > Never mind, found the GICC_DIR (offset 0x1000) register. > > -- > Anup > >> >> -- >> Anup >> >>> >>> Signed-off-by: Ian Campbell >>> Cc: devicetree@vger.kernel.org >>> Cc: linux-arm-ker...@lists.infradead.org >>> Cc: Kumar Sankaran >>> Cc: Loc Ho >>> Cc: Feng Kan >>> --- >>> Documentation/devicetree/bindings/arm/gic.txt | 57 >>> +-- >>> arch/arm64/boot/dts/apm-storm.dtsi| 6 ++- >>> 2 files changed, 50 insertions(+), 13 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt >>> b/Documentation/devicetree/bindings/arm/gic.txt >>> index ea215e8..00836d9 100644 >>> --- a/Documentation/devicetree/bindings/arm/gic.txt >>> +++ b/Documentation/devicetree/bindings/arm/gic.txt >>> @@ -38,7 +38,8 @@ Main node required properties: >>> >>> - reg : Specifies base physical address(s) and size of the GIC registers. >>> The >>>first region is the GIC distributor register base and size. The 2nd >>> region is >>> - the GIC cpu interface register base and size. >>> + the GIC cpu interface register base and size (See also "Split GIC >>> + cpu interface", below). >>> >>> Optional >>> - interrupts : Interrupt source of the parent interrupt controller on >>> @@ -56,8 +57,8 @@ Example: >>> #interrupt-cells = <3>; >>> #address-cells = <1>; >>> interrupt-controller; >>> - reg = <0xfff11000 0x1000>, >>> - <0xfff10100 0x100>; >>> + reg = <0xfff11000 0x1000>, /* GIC Dist */ >>> + <0xfff10100 0x100>; /* GIC CPU */ >>> }; >>> >>> >>> @@ -70,9 +71,11 @@ primary interrupt controller). >>> Required properties: >>> >>> - reg : Additional regions specifying the base physical address and >>> - size of the VGIC registers. The first additional region is the GIC >>> - virtual interface control register base and size. The 2nd additional >>> - region is the GIC virtual cpu interface register base and size. >>> + size of the VGIC registers. The first additional region (i.e. third >>> + overall) is the GIC virtual interface control register base and >>> + size. The 2nd additional region (i.e. forth overall) is the GIC >>> + virtual cpu interface register base and size (See also "Split GIC >>> + cpu interface", below). >>> >>> - interrupts : VGIC maintenance interrupt. >>> >>> @@ -82,9 +85,41 @@ Example: >>> compatible = "arm,cortex-a15-gic"; >>> #interrupt-cells = <3>; >>> interrupt-controller; >>> - reg = <0x2c001000 0x1000>, >>> - <0x2c002000 0x2000>, >>> - <0x2c004000 0x2000>, >>> - <0x2c006000 0x2000>; >>> - interrupts = <1 9 0xf04>; >>> + reg = <0x2c001000 0x1000>, /* GIC Di
Re: [PATCH 2/2] arm: Support for platforms with split GIC cpu interface registers.
On Fri, Nov 22, 2013 at 12:24 PM, Anup Patel wrote: > On Fri, Nov 1, 2013 at 3:43 PM, Ian Campbell wrote: >> At least one platform (APM Storm) places the two pages of the GIC cpu >> interface >> (and the vcpu side) at non-contiguous locations. Document two additional >> regions to cover this split and update the corresponding dtsi. Note that >> Linux >> (including KVM) does not use any registers in the second page so there is no >> associated code change here. Xen will use these new regions, although I've >> not >> written the corresponding code yet. >> >> The ordering of these new regs is slightly counter intuitive but is inteded >> to >> be backward compatible. It is also assumed that all such systems will >> implement >> the GIC virtualisation extensions. >> >> Add comments to all of the reg examples to help clarify what is going on. > > Adding Catalin, Marc Z, and Will D. > > I looked up the GIC-400 TRM (more specifically page 33 of > DDI0471B_gic400_r0p1_trm.pdf) but could not find any info > on additional page for CPU interface. > > Am I looking at the wrong doc? Never mind, found the GICC_DIR (offset 0x1000) register. -- Anup > > -- > Anup > >> >> Signed-off-by: Ian Campbell >> Cc: devicetree@vger.kernel.org >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: Kumar Sankaran >> Cc: Loc Ho >> Cc: Feng Kan >> --- >> Documentation/devicetree/bindings/arm/gic.txt | 57 >> +-- >> arch/arm64/boot/dts/apm-storm.dtsi| 6 ++- >> 2 files changed, 50 insertions(+), 13 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/arm/gic.txt >> b/Documentation/devicetree/bindings/arm/gic.txt >> index ea215e8..00836d9 100644 >> --- a/Documentation/devicetree/bindings/arm/gic.txt >> +++ b/Documentation/devicetree/bindings/arm/gic.txt >> @@ -38,7 +38,8 @@ Main node required properties: >> >> - reg : Specifies base physical address(s) and size of the GIC registers. >> The >>first region is the GIC distributor register base and size. The 2nd >> region is >> - the GIC cpu interface register base and size. >> + the GIC cpu interface register base and size (See also "Split GIC >> + cpu interface", below). >> >> Optional >> - interrupts : Interrupt source of the parent interrupt controller on >> @@ -56,8 +57,8 @@ Example: >> #interrupt-cells = <3>; >> #address-cells = <1>; >> interrupt-controller; >> - reg = <0xfff11000 0x1000>, >> - <0xfff10100 0x100>; >> + reg = <0xfff11000 0x1000>, /* GIC Dist */ >> + <0xfff10100 0x100>; /* GIC CPU */ >> }; >> >> >> @@ -70,9 +71,11 @@ primary interrupt controller). >> Required properties: >> >> - reg : Additional regions specifying the base physical address and >> - size of the VGIC registers. The first additional region is the GIC >> - virtual interface control register base and size. The 2nd additional >> - region is the GIC virtual cpu interface register base and size. >> + size of the VGIC registers. The first additional region (i.e. third >> + overall) is the GIC virtual interface control register base and >> + size. The 2nd additional region (i.e. forth overall) is the GIC >> + virtual cpu interface register base and size (See also "Split GIC >> + cpu interface", below). >> >> - interrupts : VGIC maintenance interrupt. >> >> @@ -82,9 +85,41 @@ Example: >> compatible = "arm,cortex-a15-gic"; >> #interrupt-cells = <3>; >> interrupt-controller; >> - reg = <0x2c001000 0x1000>, >> - <0x2c002000 0x2000>, >> - <0x2c004000 0x2000>, >> - <0x2c006000 0x2000>; >> - interrupts = <1 9 0xf04>; >> + reg = <0x2c001000 0x1000>, /* GIC Dist */ >> + <0x2c002000 0x2000>, /* GIC CPU */ >> + <0x2c004000 0x2000>, /* GIC VCPU Control */ >> + <0x2c006000 0x2000>; /* GIC VCPU1 */ >> + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */ >> + }; >> + >> +* Split GIC cpu interface >> + >> + The cpu interfaces (bare-metal in r
Re: [PATCH 2/2] arm: Support for platforms with split GIC cpu interface registers.
On Fri, Nov 1, 2013 at 3:43 PM, Ian Campbell wrote:
> At least one platform (APM Storm) places the two pages of the GIC cpu
> interface
> (and the vcpu side) at non-contiguous locations. Document two additional
> regions to cover this split and update the corresponding dtsi. Note that Linux
> (including KVM) does not use any registers in the second page so there is no
> associated code change here. Xen will use these new regions, although I've
> not
> written the corresponding code yet.
>
> The ordering of these new regs is slightly counter intuitive but is inteded to
> be backward compatible. It is also assumed that all such systems will
> implement
> the GIC virtualisation extensions.
>
> Add comments to all of the reg examples to help clarify what is going on.
Adding Catalin, Marc Z, and Will D.
I looked up the GIC-400 TRM (more specifically page 33 of
DDI0471B_gic400_r0p1_trm.pdf) but could not find any info
on additional page for CPU interface.
Am I looking at the wrong doc?
--
Anup
>
> Signed-off-by: Ian Campbell
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Kumar Sankaran
> Cc: Loc Ho
> Cc: Feng Kan
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 57
> +--
> arch/arm64/boot/dts/apm-storm.dtsi| 6 ++-
> 2 files changed, 50 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt
> b/Documentation/devicetree/bindings/arm/gic.txt
> index ea215e8..00836d9 100644
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -38,7 +38,8 @@ Main node required properties:
>
> - reg : Specifies base physical address(s) and size of the GIC registers. The
>first region is the GIC distributor register base and size. The 2nd region
> is
> - the GIC cpu interface register base and size.
> + the GIC cpu interface register base and size (See also "Split GIC
> + cpu interface", below).
>
> Optional
> - interrupts : Interrupt source of the parent interrupt controller on
> @@ -56,8 +57,8 @@ Example:
> #interrupt-cells = <3>;
> #address-cells = <1>;
> interrupt-controller;
> - reg = <0xfff11000 0x1000>,
> - <0xfff10100 0x100>;
> + reg = <0xfff11000 0x1000>, /* GIC Dist */
> + <0xfff10100 0x100>; /* GIC CPU */
> };
>
>
> @@ -70,9 +71,11 @@ primary interrupt controller).
> Required properties:
>
> - reg : Additional regions specifying the base physical address and
> - size of the VGIC registers. The first additional region is the GIC
> - virtual interface control register base and size. The 2nd additional
> - region is the GIC virtual cpu interface register base and size.
> + size of the VGIC registers. The first additional region (i.e. third
> + overall) is the GIC virtual interface control register base and
> + size. The 2nd additional region (i.e. forth overall) is the GIC
> + virtual cpu interface register base and size (See also "Split GIC
> + cpu interface", below).
>
> - interrupts : VGIC maintenance interrupt.
>
> @@ -82,9 +85,41 @@ Example:
> compatible = "arm,cortex-a15-gic";
> #interrupt-cells = <3>;
> interrupt-controller;
> - reg = <0x2c001000 0x1000>,
> - <0x2c002000 0x2000>,
> - <0x2c004000 0x2000>,
> - <0x2c006000 0x2000>;
> - interrupts = <1 9 0xf04>;
> + reg = <0x2c001000 0x1000>, /* GIC Dist */
> + <0x2c002000 0x2000>, /* GIC CPU */
> + <0x2c004000 0x2000>, /* GIC VCPU Control */
> + <0x2c006000 0x2000>; /* GIC VCPU1 */
> + interrupts = <1 9 0xf04>; /* GIC Maintenence IRQ */
> + };
> +
> +* Split GIC cpu interface
> +
> + The cpu interfaces (bare-metal in region 2 and virtual in region 4)
> + may be spread over two pages, with the GICC_DIR (Deactivate
> + Interrupt Register) register falling at the start of the second
> + page. If these pages are contiguous then this is described via the
> + size of the second and fourth entries as described above
> + (e.g. 0x2000 rather than 0x1000).
> +
> + However if the two pages are not contiguous then two additional
> + regions are present (5th and 6th) describing the location of the the
> + second half of the GIC cpu interface and GIC virtual cpu interface
> + respectively.
> +
> + It is assumed that all such systems will implement the GIC
> + virtualisation extensions.
> +
> +Example:
> +
> + gic: interrupt-controller@7801 {
> + compatible = "arm,cortex-a15-gic";
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x7801 0x1000>, /* GIC Dist */
> + <0x78
