Re: [PATCH v7 2/2] mtd: nand: Add support for Arasan NAND Flash Controller
Hi Boris,
Thanks for the review
On Sun, Feb 19, 2017 at 3:56 PM, Boris Brezillon
<boris.brezil...@free-electrons.com> wrote:
> Hi Punnaiah,
>
> Sorry for the late reply.
>
> On Mon, 9 Jan 2017 08:28:54 +0530
> Punnaiah Choudary Kalluri <punnaiah.choudary.kall...@xilinx.com> wrote:
>
>> Added the basic driver for Arasan NAND Flash Controller used in
>> Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit
>> correction.
>>
>> Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
>> ---
>> Changes in v7:
>> - Implemented Marek suggestions and comments
>> - Corrected the acronyms those should be in caps
>> - Modified kconfig/Make file to keep arasan entry in sorted order
>> - Added is_vmlloc_addr check
>> - Used ioread/write32_rep variants to avoid compilation error for intel
>> platforms
>> - separated PIO and DMA mode read/write functions
>> - Minor cleanup
>> Chnages in v6:
>> - Addressed most of the Brian and Boris comments
>> - Separated the nandchip from the nand controller
>> - Removed the ecc lookup table from driver
>> - Now use framework nand waitfunction and readoob
>> - Fixed the compiler warning
>> - Adapted the new frameowrk changes related to ecc and ooblayout
>> - Disabled the clocks after the nand_reelase
>> - Now using only one completion object
>> - Boris suggessions like adapting cmd_ctrl and rework on read/write byte
>> are not implemented and i will patch them later
>> - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will
>> implement later once the basic driver is mainlined.
>> Changes in v5:
>> - Renamed the driver filei as arasan_nand.c
>> - Fixed all comments relaqted coding style
>> - Fixed comments related to propagating the errors
>> - Modified the anfc_write_page_hwecc as per the write_page
>> prototype
>> Changes in v4:
>> - Added support for onfi timing mode configuration
>> - Added clock suort
>> - Added support for multiple chipselects
>> Changes in v3:
>> - Removed unused variables
>> - Avoided busy loop and used jifies based implementation
>> - Fixed compiler warnings "right shift count >= width of type"
>> - Removed unneeded codei and improved error reporting
>> - Added onfi version check to ensure reading the valid address cycles
>> Changes in v2:
>> - Added missing of.h to avoid kbuild system report erro
>> ---
>> drivers/mtd/nand/Kconfig | 8 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/arasan_nand.c | 932
>> +
>> 3 files changed, 941 insertions(+)
>> create mode 100644 drivers/mtd/nand/arasan_nand.c
>
> checkpatch.pl --strict reports a few coding style problems. Can you fix
> them?
>
Ok.
> [...]
>
>> +#define PROG_PGRDBIT(0)
>> +#define PROG_ERASE BIT(2)
>> +#define PROG_STATUS BIT(3)
>> +#define PROG_PGPROG BIT(4)
>> +#define PROG_RDIDBIT(6)
>> +#define PROG_RDPARAM BIT(7)
>> +#define PROG_RST BIT(8)
>> +#define PROG_GET_FEATURE BIT(9)
>> +#define PROG_SET_FEATURE BIT(10)
>
> I know I'm being insistent on this, but I don't understand what these
> different prog modes are meant for. You still have to set the NAND
> command and address cycles, so it probably has to do with timing
> sequences, but that's not clearly described in the doc you pointed.
>
As per the spec, deepening on the operation to be perform,
the corresponding program bit need to be set. After this step, the controller
will initiate the cmd and data phase sequence.But even i am not sure why
we need to program though the required parameters are already configured
probably the controller internal state machine might need this information.
> [...]
>
>> +static void anfc_rw_buf_dma(struct mtd_info *mtd, uint8_t *buf, int len,
>> + int operation, u32 prog)
>> +{
>> + dma_addr_t paddr;
>> + struct nand_chip *chip = mtd_to_nand(mtd);
>> + struct anfc *nfc = to_anfc(chip->controller);
>> + struct anfc_nand_chip *achip = to_anfc_nand(chip);
>> + u32 eccintr = 0, dir;
>> + u32 pktsize = len, pktcount = 1;
>> +
>> + if ((nfc->curr_cmd == NAND_CMD_READ0) ||
>> + ((nfc->curr_cmd == NAND_CMD_SEQIN) && !nfc->iswriteoob)) {
>> + pktsize = achip->pktsize;
>> + pktcount = DIV_ROUND_UP(mtd
Re: [PATCH v7 2/2] mtd: nand: Add support for Arasan NAND Flash Controller
Hi Boris,
Thanks for the review
On Sun, Feb 19, 2017 at 3:56 PM, Boris Brezillon
wrote:
> Hi Punnaiah,
>
> Sorry for the late reply.
>
> On Mon, 9 Jan 2017 08:28:54 +0530
> Punnaiah Choudary Kalluri wrote:
>
>> Added the basic driver for Arasan NAND Flash Controller used in
>> Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit
>> correction.
>>
>> Signed-off-by: Punnaiah Choudary Kalluri
>> ---
>> Changes in v7:
>> - Implemented Marek suggestions and comments
>> - Corrected the acronyms those should be in caps
>> - Modified kconfig/Make file to keep arasan entry in sorted order
>> - Added is_vmlloc_addr check
>> - Used ioread/write32_rep variants to avoid compilation error for intel
>> platforms
>> - separated PIO and DMA mode read/write functions
>> - Minor cleanup
>> Chnages in v6:
>> - Addressed most of the Brian and Boris comments
>> - Separated the nandchip from the nand controller
>> - Removed the ecc lookup table from driver
>> - Now use framework nand waitfunction and readoob
>> - Fixed the compiler warning
>> - Adapted the new frameowrk changes related to ecc and ooblayout
>> - Disabled the clocks after the nand_reelase
>> - Now using only one completion object
>> - Boris suggessions like adapting cmd_ctrl and rework on read/write byte
>> are not implemented and i will patch them later
>> - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will
>> implement later once the basic driver is mainlined.
>> Changes in v5:
>> - Renamed the driver filei as arasan_nand.c
>> - Fixed all comments relaqted coding style
>> - Fixed comments related to propagating the errors
>> - Modified the anfc_write_page_hwecc as per the write_page
>> prototype
>> Changes in v4:
>> - Added support for onfi timing mode configuration
>> - Added clock suort
>> - Added support for multiple chipselects
>> Changes in v3:
>> - Removed unused variables
>> - Avoided busy loop and used jifies based implementation
>> - Fixed compiler warnings "right shift count >= width of type"
>> - Removed unneeded codei and improved error reporting
>> - Added onfi version check to ensure reading the valid address cycles
>> Changes in v2:
>> - Added missing of.h to avoid kbuild system report erro
>> ---
>> drivers/mtd/nand/Kconfig | 8 +
>> drivers/mtd/nand/Makefile | 1 +
>> drivers/mtd/nand/arasan_nand.c | 932
>> +
>> 3 files changed, 941 insertions(+)
>> create mode 100644 drivers/mtd/nand/arasan_nand.c
>
> checkpatch.pl --strict reports a few coding style problems. Can you fix
> them?
>
Ok.
> [...]
>
>> +#define PROG_PGRDBIT(0)
>> +#define PROG_ERASE BIT(2)
>> +#define PROG_STATUS BIT(3)
>> +#define PROG_PGPROG BIT(4)
>> +#define PROG_RDIDBIT(6)
>> +#define PROG_RDPARAM BIT(7)
>> +#define PROG_RST BIT(8)
>> +#define PROG_GET_FEATURE BIT(9)
>> +#define PROG_SET_FEATURE BIT(10)
>
> I know I'm being insistent on this, but I don't understand what these
> different prog modes are meant for. You still have to set the NAND
> command and address cycles, so it probably has to do with timing
> sequences, but that's not clearly described in the doc you pointed.
>
As per the spec, deepening on the operation to be perform,
the corresponding program bit need to be set. After this step, the controller
will initiate the cmd and data phase sequence.But even i am not sure why
we need to program though the required parameters are already configured
probably the controller internal state machine might need this information.
> [...]
>
>> +static void anfc_rw_buf_dma(struct mtd_info *mtd, uint8_t *buf, int len,
>> + int operation, u32 prog)
>> +{
>> + dma_addr_t paddr;
>> + struct nand_chip *chip = mtd_to_nand(mtd);
>> + struct anfc *nfc = to_anfc(chip->controller);
>> + struct anfc_nand_chip *achip = to_anfc_nand(chip);
>> + u32 eccintr = 0, dir;
>> + u32 pktsize = len, pktcount = 1;
>> +
>> + if ((nfc->curr_cmd == NAND_CMD_READ0) ||
>> + ((nfc->curr_cmd == NAND_CMD_SEQIN) && !nfc->iswriteoob)) {
>> + pktsize = achip->pktsize;
>> + pktcount = DIV_ROUND_UP(mtd->writesize, pktsize);
>> + }
>
> I really don't like what's done here (the fact that you tes
RE: [PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
Hi Boris, Thanks. I will implement these changes and send the next series. Regards, Punnaiah > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com] > Sent: Tuesday, January 10, 2017 1:36 PM > To: Punnaiah Choudary Kalluri <punn...@xilinx.com> > Cc: Rob Herring <r...@kernel.org>; dw...@infradead.org; > computersforpe...@gmail.com; marek.va...@gmail.com; rich...@nod.at; > cyrille.pitc...@atmel.com; mark.rutl...@arm.com; linux- > ker...@vger.kernel.org; linux-...@lists.infradead.org; > devicet...@vger.kernel.org; Michal Simek <mich...@xilinx.com>; > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > documentation > > Hi Punnaiah, > > On Tue, 10 Jan 2017 06:03:25 + > Punnaiah Choudary Kalluri <punnaiah.choudary.kall...@xilinx.com> wrote: > > > Hi Rob, > > > >Thanks for the review. > > > > > -Original Message- > > > From: Rob Herring [mailto:r...@kernel.org] > > > Sent: Tuesday, January 10, 2017 11:06 AM > > > To: Punnaiah Choudary Kalluri <punn...@xilinx.com> > > > Cc: dw...@infradead.org; computersforpe...@gmail.com; > > > boris.brezil...@free-electrons.com; marek.va...@gmail.com; > > > rich...@nod.at; cyrille.pitc...@atmel.com; mark.rutl...@arm.com; > linux- > > > ker...@vger.kernel.org; linux-...@lists.infradead.org; > > > devicet...@vger.kernel.org; Michal Simek <mich...@xilinx.com>; > > > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > > > Choudary Kalluri <punn...@xilinx.com> > > > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > > > documentation > > > > > > On Mon, Jan 09, 2017 at 08:28:53AM +0530, Punnaiah Choudary Kalluri > wrote: > > > > This patch adds the dts binding document for arasan nand flash > > > > controller. > > > > > > > > Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> > > > > --- > > > > Changes in v7: > > > > - Corrected the acronyms those should be in caps > > > > changes in v6: > > > > - Removed num-cs property > > > > - Separated nandchip from nand controller > > > > changes in v5: > > > > - None > > > > Changes in v4: > > > > - Added num-cs property > > > > - Added clock support > > > > Changes in v3: > > > > - None > > > > Changes in v2: > > > > - None > > > > --- > > > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38 > > > ++ > > > > 1 file changed, 38 insertions(+) > > > > create mode 100644 > > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > new file mode 100644 > > > > index 000..f20adfc > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > @@ -0,0 +1,38 @@ > > > > +Arasan NAND Flash Controller with ONFI 3.1 support > > > > + > > > > +Required properties: > > > > +- compatible: Should be "arasan,nfc-v3p10" > > > > > > Needs a note that it must also have an SoC specific compatible string. > > > > > Sorry, I couldn't understand this comment. Could you elaborate it? > > Arasan is an IP vendor, and those IPs are usually embedded in specific > SoCs. I guess Rob was suggesting to define something like: > > compatible = ",", "arasan,"; > > This way you can differentiate minor changes/tweaks between each SoC > (each SoC vendor usually enable/disable specific features based on > their needs). > > > > > > > +- reg: Memory map for module access > > > > +- interrupt-parent: Interrupt controller the interrupt is routed > > > > through > > > > +- interrupts: Should contain the interrupt for the device > > > > +- clock-name: List of input clocks - "clk_sys", "clk_flash" > > > > > > clk_ is redundant. > > > > > > > I have defined these clock names as per the controller data sheet. > > So, I feel it is fine to have them in sync with the datasheet. > > Please let me know if you still want me to change this. > > We already know this is a clock, hence the unneeded clk_ prefix. Please > drop it. > > Thanks, > > Boris
RE: [PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
Hi Boris, Thanks. I will implement these changes and send the next series. Regards, Punnaiah > -Original Message- > From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com] > Sent: Tuesday, January 10, 2017 1:36 PM > To: Punnaiah Choudary Kalluri > Cc: Rob Herring ; dw...@infradead.org; > computersforpe...@gmail.com; marek.va...@gmail.com; rich...@nod.at; > cyrille.pitc...@atmel.com; mark.rutl...@arm.com; linux- > ker...@vger.kernel.org; linux-...@lists.infradead.org; > devicet...@vger.kernel.org; Michal Simek ; > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > documentation > > Hi Punnaiah, > > On Tue, 10 Jan 2017 06:03:25 + > Punnaiah Choudary Kalluri wrote: > > > Hi Rob, > > > >Thanks for the review. > > > > > -Original Message- > > > From: Rob Herring [mailto:r...@kernel.org] > > > Sent: Tuesday, January 10, 2017 11:06 AM > > > To: Punnaiah Choudary Kalluri > > > Cc: dw...@infradead.org; computersforpe...@gmail.com; > > > boris.brezil...@free-electrons.com; marek.va...@gmail.com; > > > rich...@nod.at; cyrille.pitc...@atmel.com; mark.rutl...@arm.com; > linux- > > > ker...@vger.kernel.org; linux-...@lists.infradead.org; > > > devicet...@vger.kernel.org; Michal Simek ; > > > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > > > Choudary Kalluri > > > Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding > > > documentation > > > > > > On Mon, Jan 09, 2017 at 08:28:53AM +0530, Punnaiah Choudary Kalluri > wrote: > > > > This patch adds the dts binding document for arasan nand flash > > > > controller. > > > > > > > > Signed-off-by: Punnaiah Choudary Kalluri > > > > --- > > > > Changes in v7: > > > > - Corrected the acronyms those should be in caps > > > > changes in v6: > > > > - Removed num-cs property > > > > - Separated nandchip from nand controller > > > > changes in v5: > > > > - None > > > > Changes in v4: > > > > - Added num-cs property > > > > - Added clock support > > > > Changes in v3: > > > > - None > > > > Changes in v2: > > > > - None > > > > --- > > > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38 > > > ++ > > > > 1 file changed, 38 insertions(+) > > > > create mode 100644 > > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > new file mode 100644 > > > > index 000..f20adfc > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > > > @@ -0,0 +1,38 @@ > > > > +Arasan NAND Flash Controller with ONFI 3.1 support > > > > + > > > > +Required properties: > > > > +- compatible: Should be "arasan,nfc-v3p10" > > > > > > Needs a note that it must also have an SoC specific compatible string. > > > > > Sorry, I couldn't understand this comment. Could you elaborate it? > > Arasan is an IP vendor, and those IPs are usually embedded in specific > SoCs. I guess Rob was suggesting to define something like: > > compatible = ",", "arasan,"; > > This way you can differentiate minor changes/tweaks between each SoC > (each SoC vendor usually enable/disable specific features based on > their needs). > > > > > > > +- reg: Memory map for module access > > > > +- interrupt-parent: Interrupt controller the interrupt is routed > > > > through > > > > +- interrupts: Should contain the interrupt for the device > > > > +- clock-name: List of input clocks - "clk_sys", "clk_flash" > > > > > > clk_ is redundant. > > > > > > > I have defined these clock names as per the controller data sheet. > > So, I feel it is fine to have them in sync with the datasheet. > > Please let me know if you still want me to change this. > > We already know this is a clock, hence the unneeded clk_ prefix. Please > drop it. > > Thanks, > > Boris
RE: [PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
Hi Rob,
Thanks for the review.
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, January 10, 2017 11:06 AM
> To: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> Cc: dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@free-electrons.com; marek.va...@gmail.com;
> rich...@nod.at; cyrille.pitc...@atmel.com; mark.rutl...@arm.com; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek <mich...@xilinx.com>;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri <punn...@xilinx.com>
> Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On Mon, Jan 09, 2017 at 08:28:53AM +0530, Punnaiah Choudary Kalluri wrote:
> > This patch adds the dts binding document for arasan nand flash
> > controller.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> > ---
> > Changes in v7:
> > - Corrected the acronyms those should be in caps
> > changes in v6:
> > - Removed num-cs property
> > - Separated nandchip from nand controller
> > changes in v5:
> > - None
> > Changes in v4:
> > - Added num-cs property
> > - Added clock support
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None
> > ---
> > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > 1 file changed, 38 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > new file mode 100644
> > index 000..f20adfc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > @@ -0,0 +1,38 @@
> > +Arasan NAND Flash Controller with ONFI 3.1 support
> > +
> > +Required properties:
> > +- compatible: Should be "arasan,nfc-v3p10"
>
> Needs a note that it must also have an SoC specific compatible string.
>
Sorry, I couldn't understand this comment. Could you elaborate it?
> > +- reg: Memory map for module access
> > +- interrupt-parent: Interrupt controller the interrupt is routed through
> > +- interrupts: Should contain the interrupt for the device
> > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
>
> clk_ is redundant.
>
I have defined these clock names as per the controller data sheet.
So, I feel it is fine to have them in sync with the datasheet.
Please let me know if you still want me to change this.
Regards,
Punnaiah
> > + (See clock bindings for details)
> > +- clocks: Clock phandles (see clock bindings for details)
> > +
> > +Optional properties:
> > +- arasan,has-mdma: Enables DMA support
> > +
> > +For NAND partition information please refer the below file
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + nand0: nand@ff10 {
> > + compatible = "arasan,nfc-v3p10"
> > + reg = <0x0 0xff10 0x1000>;
> > + clock-name = "clk_sys", "clk_flash"
> > + clocks = <_clk _clk>;
> > + interrupt-parent = <>;
> > + interrupts = <0 14 4>;
> > + arasan,has-mdma;
> > + #address-cells = <1>;
> > + #size-cells = <0>
> > +
> > + nand@0 {
> > + reg = <0>
> > + partition@0 {
> > + label = "filesystem";
> > + reg = <0x0 0x0 0x100>;
> > + };
> > + (...)
> > + };
> > + };
> > --
> > 2.7.4
> >
> > --
> > 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 v7 1/2] mtd: arasan: Add device tree binding documentation
Hi Rob,
Thanks for the review.
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Tuesday, January 10, 2017 11:06 AM
> To: Punnaiah Choudary Kalluri
> Cc: dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@free-electrons.com; marek.va...@gmail.com;
> rich...@nod.at; cyrille.pitc...@atmel.com; mark.rutl...@arm.com; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek ;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri
> Subject: Re: [PATCH v7 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On Mon, Jan 09, 2017 at 08:28:53AM +0530, Punnaiah Choudary Kalluri wrote:
> > This patch adds the dts binding document for arasan nand flash
> > controller.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri
> > ---
> > Changes in v7:
> > - Corrected the acronyms those should be in caps
> > changes in v6:
> > - Removed num-cs property
> > - Separated nandchip from nand controller
> > changes in v5:
> > - None
> > Changes in v4:
> > - Added num-cs property
> > - Added clock support
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None
> > ---
> > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > 1 file changed, 38 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > new file mode 100644
> > index 000..f20adfc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > @@ -0,0 +1,38 @@
> > +Arasan NAND Flash Controller with ONFI 3.1 support
> > +
> > +Required properties:
> > +- compatible: Should be "arasan,nfc-v3p10"
>
> Needs a note that it must also have an SoC specific compatible string.
>
Sorry, I couldn't understand this comment. Could you elaborate it?
> > +- reg: Memory map for module access
> > +- interrupt-parent: Interrupt controller the interrupt is routed through
> > +- interrupts: Should contain the interrupt for the device
> > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
>
> clk_ is redundant.
>
I have defined these clock names as per the controller data sheet.
So, I feel it is fine to have them in sync with the datasheet.
Please let me know if you still want me to change this.
Regards,
Punnaiah
> > + (See clock bindings for details)
> > +- clocks: Clock phandles (see clock bindings for details)
> > +
> > +Optional properties:
> > +- arasan,has-mdma: Enables DMA support
> > +
> > +For NAND partition information please refer the below file
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + nand0: nand@ff10 {
> > + compatible = "arasan,nfc-v3p10"
> > + reg = <0x0 0xff10 0x1000>;
> > + clock-name = "clk_sys", "clk_flash"
> > + clocks = <_clk _clk>;
> > + interrupt-parent = <>;
> > + interrupts = <0 14 4>;
> > + arasan,has-mdma;
> > + #address-cells = <1>;
> > + #size-cells = <0>
> > +
> > + nand@0 {
> > + reg = <0>
> > + partition@0 {
> > + label = "filesystem";
> > + reg = <0x0 0x0 0x100>;
> > + };
> > + (...)
> > + };
> > + };
> > --
> > 2.7.4
> >
> > --
> > 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 v7 2/2] mtd: nand: Add support for Arasan NAND Flash Controller
Added the basic driver for Arasan NAND Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> --- Changes in v7: - Implemented Marek suggestions and comments - Corrected the acronyms those should be in caps - Modified kconfig/Make file to keep arasan entry in sorted order - Added is_vmlloc_addr check - Used ioread/write32_rep variants to avoid compilation error for intel platforms - separated PIO and DMA mode read/write functions - Minor cleanup Chnages in v6: - Addressed most of the Brian and Boris comments - Separated the nandchip from the nand controller - Removed the ecc lookup table from driver - Now use framework nand waitfunction and readoob - Fixed the compiler warning - Adapted the new frameowrk changes related to ecc and ooblayout - Disabled the clocks after the nand_reelase - Now using only one completion object - Boris suggessions like adapting cmd_ctrl and rework on read/write byte are not implemented and i will patch them later - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will implement later once the basic driver is mainlined. Changes in v5: - Renamed the driver filei as arasan_nand.c - Fixed all comments relaqted coding style - Fixed comments related to propagating the errors - Modified the anfc_write_page_hwecc as per the write_page prototype Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report erro --- drivers/mtd/nand/Kconfig | 8 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/arasan_nand.c | 932 + 3 files changed, 941 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 7b7a887..c4cfca2 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -41,6 +41,14 @@ config MTD_SM_COMMON tristate default n +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + depends on HAS_IOMEM + depends on HAS_DMA + help + Enables the driver for the Arasan NAND Flash controller on + Zynq UltraScale+ MPSoC. + config MTD_NAND_DENALI tristate diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index cafde6f..7754170 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o obj-$(CONFIG_MTD_NAND_IDS) += nand_ids.o obj-$(CONFIG_MTD_SM_COMMON)+= sm_common.o +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o obj-$(CONFIG_MTD_NAND_CAFE)+= cafe_nand.o obj-$(CONFIG_MTD_NAND_AMS_DELTA) += ams-delta.o obj-$(CONFIG_MTD_NAND_DENALI) += denali.o diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c new file mode 100644 index 000..2103134 --- /dev/null +++ b/drivers/mtd/nand/arasan_nand.c @@ -0,0 +1,932 @@ +/* + * Arasan NAND Flash Controller Driver + * + * Copyright (C) 2014 - 2017 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nand" +#define EVNT_TIMEOUT_MSEC 1000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_OFST0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENAB
[PATCH v7 2/2] mtd: nand: Add support for Arasan NAND Flash Controller
Added the basic driver for Arasan NAND Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v7: - Implemented Marek suggestions and comments - Corrected the acronyms those should be in caps - Modified kconfig/Make file to keep arasan entry in sorted order - Added is_vmlloc_addr check - Used ioread/write32_rep variants to avoid compilation error for intel platforms - separated PIO and DMA mode read/write functions - Minor cleanup Chnages in v6: - Addressed most of the Brian and Boris comments - Separated the nandchip from the nand controller - Removed the ecc lookup table from driver - Now use framework nand waitfunction and readoob - Fixed the compiler warning - Adapted the new frameowrk changes related to ecc and ooblayout - Disabled the clocks after the nand_reelase - Now using only one completion object - Boris suggessions like adapting cmd_ctrl and rework on read/write byte are not implemented and i will patch them later - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will implement later once the basic driver is mainlined. Changes in v5: - Renamed the driver filei as arasan_nand.c - Fixed all comments relaqted coding style - Fixed comments related to propagating the errors - Modified the anfc_write_page_hwecc as per the write_page prototype Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report erro --- drivers/mtd/nand/Kconfig | 8 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/arasan_nand.c | 932 + 3 files changed, 941 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 7b7a887..c4cfca2 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -41,6 +41,14 @@ config MTD_SM_COMMON tristate default n +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + depends on HAS_IOMEM + depends on HAS_DMA + help + Enables the driver for the Arasan NAND Flash controller on + Zynq UltraScale+ MPSoC. + config MTD_NAND_DENALI tristate diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index cafde6f..7754170 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o obj-$(CONFIG_MTD_NAND_IDS) += nand_ids.o obj-$(CONFIG_MTD_SM_COMMON)+= sm_common.o +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o obj-$(CONFIG_MTD_NAND_CAFE)+= cafe_nand.o obj-$(CONFIG_MTD_NAND_AMS_DELTA) += ams-delta.o obj-$(CONFIG_MTD_NAND_DENALI) += denali.o diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c new file mode 100644 index 000..2103134 --- /dev/null +++ b/drivers/mtd/nand/arasan_nand.c @@ -0,0 +1,932 @@ +/* + * Arasan NAND Flash Controller Driver + * + * Copyright (C) 2014 - 2017 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nand" +#define EVNT_TIMEOUT_MSEC 1000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_OFST0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENABLE
[PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
---
Changes in v7:
- Corrected the acronyms those should be in caps
changes in v6:
- Removed num-cs property
- Separated nandchip from nand controller
changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..f20adfc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,38 @@
+Arasan NAND Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables DMA support
+
+For NAND partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ #address-cells = <1>;
+ #size-cells = <0>
+
+ nand@0 {
+ reg = <0>
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
+ };
--
2.7.4
[PATCH v7 1/2] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri
---
Changes in v7:
- Corrected the acronyms those should be in caps
changes in v6:
- Removed num-cs property
- Separated nandchip from nand controller
changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..f20adfc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,38 @@
+Arasan NAND Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables DMA support
+
+For NAND partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ #address-cells = <1>;
+ #size-cells = <0>
+
+ nand@0 {
+ reg = <0>
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
+ };
--
2.7.4
RE: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
> Sent: Monday, December 05, 2016 2:31 PM
> To: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> Cc: Florian Fainelli <f.faine...@gmail.com>; Kevin Hao
> <haoke...@gmail.com>; g...@denx.de; linux-kernel@vger.kernel.org; Andy
> Shevchenko <andriy.shevche...@linux.intel.com>; Punnaiah Choudary
> <kpc...@gmail.com>; wangzh...@hisilicon.com; ge...@linux-m68k.org;
> Ezequiel Garcia <ezequ...@vanguardiasur.com.ar>; linux-
> m...@lists.infradead.org; Punnaiah Choudary Kalluri <punn...@xilinx.com>;
> Michal Simek <mich...@xilinx.com>; Brian Norris
> <computersforpe...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; rog...@ti.com; Marek Vasut <ma...@denx.de>
> Subject: Re: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash
> Controller
>
> +Marek who reviewed v6
>
> Hi Punnaiah,
>
> I see you sent a v6, but you never answered the questions/remarks I had in
> this email.
>
My appolgies. Somehow I missed the below mail.
> Can you please try to answer them (I'd like to understand how the controller
> works)?
>
Sure.
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
NAND chapter starts from page 577
> Thanks,
>
> Boris
>
> On Wed, 9 Mar 2016 10:50:07 +0100
> Boris Brezillon <boris.brezil...@free-electrons.com> wrote:
>
> > Hi Punnaiah,
> >
> > On Wed, 9 Mar 2016 00:10:52 +0530
> > punnaiah choudary kalluri <punn...@xilinx.com> wrote:
> >
> >
> > > >> +static const struct anfc_ecc_matrix ecc_matrix[] = {
> > > >> + {512, 512,1, 0, 0x3},
> > > >> + {512, 512,4, 1, 0x7},
> > > >> + {512, 512,8, 1, 0xD},
> > > >> + /* 2K byte page */
> > > >> + {2048, 512,1, 0, 0xC},
> > > >> + {2048, 512,4, 1, 0x1A},
> > > >> + {2048, 512,8, 1, 0x34},
> > > >> + {2048, 512,12, 1, 0x4E},
> > > >> + {2048, 1024, 24, 1, 0x54},
> > > >> + /* 4K byte page */
> > > >> + {4096, 512,1, 0, 0x18},
> > > >> + {4096, 512,4, 1, 0x34},
> > > >> + {4096, 512,8, 1, 0x68},
> > > >> + {4096, 512,12, 1, 0x9C},
> > > >> + {4096, 1024, 4, 1, 0xA8},
> > > >> + /* 8K byte page */
> > > >> + {8192, 512,1, 0, 0x30},
> > > >> + {8192, 512,4, 1, 0x68},
> > > >> + {8192, 512,8, 1, 0xD0},
> > > >> + {8192, 512,12, 1, 0x138},
> > > >> + {8192, 1024, 24, 1, 0x150},
> > > >> + /* 16K byte page */
> > > >> + {16384, 512,1, 0, 0x60},
> > > >> + {16384, 512,4, 1, 0xD0},
> > > >> + {16384, 512,8, 1, 0x1A0},
> > > >> + {16384, 512,12, 1, 0x270},
> > > >> + {16384, 1024, 24, 1, 0x2A0}
> > > >> +};
> > > >
> > > > Do you really need this association table. IMO, those are
> > > > information you could deduce from nand_chip info (ecc_strength,
> > > > ecc_step_size, ...). eccsize can be calculated this way:
> > > >
> > > > info->pagesize = mtd->writesize;
> > > > info->codeword_size = chip->ecc_step_ds;
> > > > info->eccbits = chip->ecc_strength_ds;
> > > >
> > > > if (info->eccbits > 1)
> > > > info->bch = true;
> > > >
> > > > steps = info->pagesize / info->codeword_size;
> > > >
> > > > if (!bch)
> > > > info->eccsize = 3 * steps;
> > > > else
> > > > info->eccsize =
> > > > DIV_ROUND_UP(fls(8 * info->codeword_size) *
> > > > ecc->strength * steps, 8);
> > > >
> > > > And, too bad we have to deal with another engine operating at the
> > > > bit level instead of aligning each ECC step to the next byte (GPMI
> > > > engine does that too, and it's a
RE: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
> Sent: Monday, December 05, 2016 2:31 PM
> To: Punnaiah Choudary Kalluri
> Cc: Florian Fainelli ; Kevin Hao
> ; g...@denx.de; linux-kernel@vger.kernel.org; Andy
> Shevchenko ; Punnaiah Choudary
> ; wangzh...@hisilicon.com; ge...@linux-m68k.org;
> Ezequiel Garcia ; linux-
> m...@lists.infradead.org; Punnaiah Choudary Kalluri ;
> Michal Simek ; Brian Norris
> ; David Woodhouse
> ; rog...@ti.com; Marek Vasut
> Subject: Re: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash
> Controller
>
> +Marek who reviewed v6
>
> Hi Punnaiah,
>
> I see you sent a v6, but you never answered the questions/remarks I had in
> this email.
>
My appolgies. Somehow I missed the below mail.
> Can you please try to answer them (I'd like to understand how the controller
> works)?
>
Sure.
https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
NAND chapter starts from page 577
> Thanks,
>
> Boris
>
> On Wed, 9 Mar 2016 10:50:07 +0100
> Boris Brezillon wrote:
>
> > Hi Punnaiah,
> >
> > On Wed, 9 Mar 2016 00:10:52 +0530
> > punnaiah choudary kalluri wrote:
> >
> >
> > > >> +static const struct anfc_ecc_matrix ecc_matrix[] = {
> > > >> + {512, 512,1, 0, 0x3},
> > > >> + {512, 512,4, 1, 0x7},
> > > >> + {512, 512,8, 1, 0xD},
> > > >> + /* 2K byte page */
> > > >> + {2048, 512,1, 0, 0xC},
> > > >> + {2048, 512,4, 1, 0x1A},
> > > >> + {2048, 512,8, 1, 0x34},
> > > >> + {2048, 512,12, 1, 0x4E},
> > > >> + {2048, 1024, 24, 1, 0x54},
> > > >> + /* 4K byte page */
> > > >> + {4096, 512,1, 0, 0x18},
> > > >> + {4096, 512,4, 1, 0x34},
> > > >> + {4096, 512,8, 1, 0x68},
> > > >> + {4096, 512,12, 1, 0x9C},
> > > >> + {4096, 1024, 4, 1, 0xA8},
> > > >> + /* 8K byte page */
> > > >> + {8192, 512,1, 0, 0x30},
> > > >> + {8192, 512,4, 1, 0x68},
> > > >> + {8192, 512,8, 1, 0xD0},
> > > >> + {8192, 512,12, 1, 0x138},
> > > >> + {8192, 1024, 24, 1, 0x150},
> > > >> + /* 16K byte page */
> > > >> + {16384, 512,1, 0, 0x60},
> > > >> + {16384, 512,4, 1, 0xD0},
> > > >> + {16384, 512,8, 1, 0x1A0},
> > > >> + {16384, 512,12, 1, 0x270},
> > > >> + {16384, 1024, 24, 1, 0x2A0}
> > > >> +};
> > > >
> > > > Do you really need this association table. IMO, those are
> > > > information you could deduce from nand_chip info (ecc_strength,
> > > > ecc_step_size, ...). eccsize can be calculated this way:
> > > >
> > > > info->pagesize = mtd->writesize;
> > > > info->codeword_size = chip->ecc_step_ds;
> > > > info->eccbits = chip->ecc_strength_ds;
> > > >
> > > > if (info->eccbits > 1)
> > > > info->bch = true;
> > > >
> > > > steps = info->pagesize / info->codeword_size;
> > > >
> > > > if (!bch)
> > > > info->eccsize = 3 * steps;
> > > > else
> > > > info->eccsize =
> > > > DIV_ROUND_UP(fls(8 * info->codeword_size) *
> > > > ecc->strength * steps, 8);
> > > >
> > > > And, too bad we have to deal with another engine operating at the
> > > > bit level instead of aligning each ECC step to the next byte (GPMI
> > > > engine does that too, and it's a pain to deal with).
> > > >
> > >
> > > 1. There is no direct formula for calculating the ecc size. For bch
> > > ecc algorithms, the ecc size can vary based on the chosen
> > > polynomial.
> >
> > I checked for all the table entries, and this formula works (note that
> > it takes the codeword_size into account, whic
RE: [PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
> Sent: Monday, December 05, 2016 2:07 PM
> To: Marek Vasut <marek.va...@gmail.com>
> Cc: Punnaiah Choudary Kalluri <punn...@xilinx.com>;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com;
> linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek <mich...@xilinx.com>;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri <punn...@xilinx.com>
> Subject: Re: [PATCH v6 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On Mon, 5 Dec 2016 05:25:54 +0100
> Marek Vasut <marek.va...@gmail.com> wrote:
>
> > On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote:
> > > This patch adds the dts binding document for arasan nand flash
> > > controller.
> > >
> > > Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> > > Acked-by: Rob Herring <r...@kernel.org>
> > > ---
> > > changes in v6:
> > > - Removed num-cs property
> > > - Separated nandchip from nand controller changes in v5:
> > > - None
> > > Changes in v4:
> > > - Added num-cs property
> > > - Added clock support
> > > Changes in v3:
> > > - None
> > > Changes in v2:
> > > - None
> > > ---
> > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > > 1 file changed, 38 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > new file mode 100644
> > > index 000..dcbe7ad
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > @@ -0,0 +1,38 @@
> > > +Arasan Nand Flash Controller with ONFI 3.1 support
> >
> > Arasan NAND Flash ...
> >
> > > +Required properties:
> > > +- compatible: Should be "arasan,nfc-v3p10"
> >
> > This v3p10 looks like version 3 patchlevel 10, but shouldn't we have
> > some fallback option which doesn't encode IP version in the compat
> > string ?
>
> Not necessarily. Usually you define a generic compatible when you have
> other reliable means to detect the IP version (a version register for
> example).
> If you can't detect that at runtime, then providing only specific compatible
> strings is a good solution to avoid breaking the DT ABI.
Yes. I am also thinking the same. Arasan controller doesn't have the register
to indicate the IP version number.
>
> >
> > Also, shouldn't quirks be handled by DT props instead of effectively
> > encoding them into the compatible string ?
>
> Well, from my experience, it's better to hide as much as possible behind the
> compatible. This way, if new quirks are needed for a specific revision, you
> can
> update the driver without having to change the DT.
>
Agree.
Regards,
Punnaiah
> >
> > > +- reg: Memory map for module access
> > > +- interrupt-parent: Interrupt controller the interrupt is routed
> > > +through
> > > +- interrupts: Should contain the interrupt for the device
> > > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
> > > + (See clock bindings for details)
> > > +- clocks: Clock phandles (see clock bindings for details)
> > > +
> > > +Optional properties:
> > > +- arasan,has-mdma: Enables Dma support
> >
> > 'Enables DMA support' , with DMA in caps.
> >
> > > +for nand partition information please refer the below file
> >
> > For NAND ...
> >
> > > +Documentation/devicetree/bindings/mtd/partition.txt
> > > +
> > > +Example:
> > > + nand0: nand@ff10 {
> > > + compatible = "arasan,nfc-v3p10"
> > > + reg = <0x0 0xff10 0x1000>;
> > > + clock-name = "clk_sys", "clk_flash"
> > > + clocks = <_clk _clk>;
> > > + interrupt-parent = <>;
> > > + interrupts = <0 14 4>;
> > > + arasan,has-mdma;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>
> > > +
> > > + nand@0 {
> > > + reg = <0>
> > > + partition@0 {
> > > + label = "filesystem";
> > > + reg = <0x0 0x0 0x100>;
> > > + };
> > > + (...)
> > > + };
> > > + };
> > >
> >
> >
RE: [PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
> Sent: Monday, December 05, 2016 2:07 PM
> To: Marek Vasut
> Cc: Punnaiah Choudary Kalluri ;
> dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at;
> cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com;
> linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek ;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri
> Subject: Re: [PATCH v6 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On Mon, 5 Dec 2016 05:25:54 +0100
> Marek Vasut wrote:
>
> > On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote:
> > > This patch adds the dts binding document for arasan nand flash
> > > controller.
> > >
> > > Signed-off-by: Punnaiah Choudary Kalluri
> > > Acked-by: Rob Herring
> > > ---
> > > changes in v6:
> > > - Removed num-cs property
> > > - Separated nandchip from nand controller changes in v5:
> > > - None
> > > Changes in v4:
> > > - Added num-cs property
> > > - Added clock support
> > > Changes in v3:
> > > - None
> > > Changes in v2:
> > > - None
> > > ---
> > > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > > 1 file changed, 38 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > new file mode 100644
> > > index 000..dcbe7ad
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > > @@ -0,0 +1,38 @@
> > > +Arasan Nand Flash Controller with ONFI 3.1 support
> >
> > Arasan NAND Flash ...
> >
> > > +Required properties:
> > > +- compatible: Should be "arasan,nfc-v3p10"
> >
> > This v3p10 looks like version 3 patchlevel 10, but shouldn't we have
> > some fallback option which doesn't encode IP version in the compat
> > string ?
>
> Not necessarily. Usually you define a generic compatible when you have
> other reliable means to detect the IP version (a version register for
> example).
> If you can't detect that at runtime, then providing only specific compatible
> strings is a good solution to avoid breaking the DT ABI.
Yes. I am also thinking the same. Arasan controller doesn't have the register
to indicate the IP version number.
>
> >
> > Also, shouldn't quirks be handled by DT props instead of effectively
> > encoding them into the compatible string ?
>
> Well, from my experience, it's better to hide as much as possible behind the
> compatible. This way, if new quirks are needed for a specific revision, you
> can
> update the driver without having to change the DT.
>
Agree.
Regards,
Punnaiah
> >
> > > +- reg: Memory map for module access
> > > +- interrupt-parent: Interrupt controller the interrupt is routed
> > > +through
> > > +- interrupts: Should contain the interrupt for the device
> > > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
> > > + (See clock bindings for details)
> > > +- clocks: Clock phandles (see clock bindings for details)
> > > +
> > > +Optional properties:
> > > +- arasan,has-mdma: Enables Dma support
> >
> > 'Enables DMA support' , with DMA in caps.
> >
> > > +for nand partition information please refer the below file
> >
> > For NAND ...
> >
> > > +Documentation/devicetree/bindings/mtd/partition.txt
> > > +
> > > +Example:
> > > + nand0: nand@ff10 {
> > > + compatible = "arasan,nfc-v3p10"
> > > + reg = <0x0 0xff10 0x1000>;
> > > + clock-name = "clk_sys", "clk_flash"
> > > + clocks = <_clk _clk>;
> > > + interrupt-parent = <>;
> > > + interrupts = <0 14 4>;
> > > + arasan,has-mdma;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>
> > > +
> > > + nand@0 {
> > > + reg = <0>
> > > + partition@0 {
> > > + label = "filesystem";
> > > + reg = <0x0 0x0 0x100>;
> > > + };
> > > + (...)
> > > + };
> > > + };
> > >
> >
> >
RE: [PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash Controller
Hi Marek, Thanks for the review and comments. > -Original Message- > From: Marek Vasut [mailto:marek.va...@gmail.com] > Sent: Monday, December 05, 2016 10:10 AM > To: Punnaiah Choudary Kalluri <punn...@xilinx.com>; > dw...@infradead.org; computersforpe...@gmail.com; > boris.brezil...@free-electrons.com; rich...@nod.at; > cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; > devicet...@vger.kernel.org; Michal Simek <mich...@xilinx.com>; > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > Choudary Kalluri <punn...@xilinx.com> > Subject: Re: [PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash > Controller > > On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote: > > Added the basic driver for Arasan Nand Flash Controller used in > > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit > > correction. > > Ummm, NAND, ECC, can you fix the acronyms to be in caps ? > Ok > > Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> > > --- > > Chnages in v6: > > - Addressed most of the Brian and Boris comments > > - Separated the nandchip from the nand controller > > - Removed the ecc lookup table from driver > > - Now use framework nand waitfunction and readoob > > - Fixed the compiler warning > > - Adapted the new frameowrk changes related to ecc and ooblayout > > - Disabled the clocks after the nand_reelase > > - Now using only one completion object > > - Boris suggessions like adapting cmd_ctrl and rework on read/write byte > > are not implemented and i will patch them later > > - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr > will > > implement later once the basic driver is mainlined. > > Changes in v5: > > - Renamed the driver filei as arasan_nand.c > > - Fixed all comments relaqted coding style > > - Fixed comments related to propagating the errors > > - Modified the anfc_write_page_hwecc as per the write_page > > prototype > > Changes in v4: > > - Added support for onfi timing mode configuration > > - Added clock suort > > - Added support for multiple chipselects > > Changes in v3: > > - Removed unused variables > > - Avoided busy loop and used jifies based implementation > > - Fixed compiler warnings "right shift count >= width of type" > > - Removed unneeded codei and improved error reporting > > - Added onfi version check to ensure reading the valid address cycles > > Changes in v2: > > - Added missing of.h to avoid kbuild system report erro > > --- > > drivers/mtd/nand/Kconfig | 8 + > > drivers/mtd/nand/Makefile | 1 + > > drivers/mtd/nand/arasan_nand.c | 974 > + > > 3 files changed, 983 insertions(+) > > create mode 100644 drivers/mtd/nand/arasan_nand.c > > > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > > index 7b7a887..e831f4e 100644 > > --- a/drivers/mtd/nand/Kconfig > > +++ b/drivers/mtd/nand/Kconfig > > @@ -569,4 +569,12 @@ config MTD_NAND_MTK > > Enables support for NAND controller on MTK SoCs. > > This controller is found on mt27xx, mt81xx, mt65xx SoCs. > > > > +config MTD_NAND_ARASAN > > + tristate "Support for Arasan Nand Flash controller" > > + depends on HAS_IOMEM > > + depends on HAS_DMA > > + help > > + Enables the driver for the Arasan Nand Flash controller on > > + Zynq UltraScale+ MPSoC. > > + > > endif # MTD_NAND > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > > index cafde6f..44b8b00 100644 > > --- a/drivers/mtd/nand/Makefile > > +++ b/drivers/mtd/nand/Makefile > > @@ -58,5 +58,6 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= > hisi504_nand.o > > obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ > > obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o > > obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o > > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o > > Keep the list at least reasonably sorted. Ok > > > nand-objs := nand_base.o nand_bbt.o nand_timings.o > > diff --git a/drivers/mtd/nand/arasan_nand.c > b/drivers/mtd/nand/arasan_nand.c > > new file mode 100644 > > index 000..6b0670e > > --- /dev/null > > +++ b/drivers/mtd/nand/arasan_nand.c > > @@ -0,0 +1,974 @@ > > +/* > > + * Arasan Nand Flash Controller Driver > > NAND &g
RE: [PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash Controller
Hi Marek, Thanks for the review and comments. > -Original Message- > From: Marek Vasut [mailto:marek.va...@gmail.com] > Sent: Monday, December 05, 2016 10:10 AM > To: Punnaiah Choudary Kalluri ; > dw...@infradead.org; computersforpe...@gmail.com; > boris.brezil...@free-electrons.com; rich...@nod.at; > cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; > devicet...@vger.kernel.org; Michal Simek ; > kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah > Choudary Kalluri > Subject: Re: [PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash > Controller > > On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote: > > Added the basic driver for Arasan Nand Flash Controller used in > > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit > > correction. > > Ummm, NAND, ECC, can you fix the acronyms to be in caps ? > Ok > > Signed-off-by: Punnaiah Choudary Kalluri > > --- > > Chnages in v6: > > - Addressed most of the Brian and Boris comments > > - Separated the nandchip from the nand controller > > - Removed the ecc lookup table from driver > > - Now use framework nand waitfunction and readoob > > - Fixed the compiler warning > > - Adapted the new frameowrk changes related to ecc and ooblayout > > - Disabled the clocks after the nand_reelase > > - Now using only one completion object > > - Boris suggessions like adapting cmd_ctrl and rework on read/write byte > > are not implemented and i will patch them later > > - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr > will > > implement later once the basic driver is mainlined. > > Changes in v5: > > - Renamed the driver filei as arasan_nand.c > > - Fixed all comments relaqted coding style > > - Fixed comments related to propagating the errors > > - Modified the anfc_write_page_hwecc as per the write_page > > prototype > > Changes in v4: > > - Added support for onfi timing mode configuration > > - Added clock suort > > - Added support for multiple chipselects > > Changes in v3: > > - Removed unused variables > > - Avoided busy loop and used jifies based implementation > > - Fixed compiler warnings "right shift count >= width of type" > > - Removed unneeded codei and improved error reporting > > - Added onfi version check to ensure reading the valid address cycles > > Changes in v2: > > - Added missing of.h to avoid kbuild system report erro > > --- > > drivers/mtd/nand/Kconfig | 8 + > > drivers/mtd/nand/Makefile | 1 + > > drivers/mtd/nand/arasan_nand.c | 974 > + > > 3 files changed, 983 insertions(+) > > create mode 100644 drivers/mtd/nand/arasan_nand.c > > > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > > index 7b7a887..e831f4e 100644 > > --- a/drivers/mtd/nand/Kconfig > > +++ b/drivers/mtd/nand/Kconfig > > @@ -569,4 +569,12 @@ config MTD_NAND_MTK > > Enables support for NAND controller on MTK SoCs. > > This controller is found on mt27xx, mt81xx, mt65xx SoCs. > > > > +config MTD_NAND_ARASAN > > + tristate "Support for Arasan Nand Flash controller" > > + depends on HAS_IOMEM > > + depends on HAS_DMA > > + help > > + Enables the driver for the Arasan Nand Flash controller on > > + Zynq UltraScale+ MPSoC. > > + > > endif # MTD_NAND > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > > index cafde6f..44b8b00 100644 > > --- a/drivers/mtd/nand/Makefile > > +++ b/drivers/mtd/nand/Makefile > > @@ -58,5 +58,6 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= > hisi504_nand.o > > obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ > > obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o > > obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o > > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o > > Keep the list at least reasonably sorted. Ok > > > nand-objs := nand_base.o nand_bbt.o nand_timings.o > > diff --git a/drivers/mtd/nand/arasan_nand.c > b/drivers/mtd/nand/arasan_nand.c > > new file mode 100644 > > index 000..6b0670e > > --- /dev/null > > +++ b/drivers/mtd/nand/arasan_nand.c > > @@ -0,0 +1,974 @@ > > +/* > > + * Arasan Nand Flash Controller Driver > > NAND > > > + * Copyright (C) 2014 - 2015 Xilinx, Inc. > > It's 2016 now ... Sorry :). Yes, I will updat
RE: [PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
Hi Marek,
Thanks for the review.
> -Original Message-
> From: Marek Vasut [mailto:marek.va...@gmail.com]
> Sent: Monday, December 05, 2016 9:56 AM
> To: Punnaiah Choudary Kalluri <punn...@xilinx.com>;
> dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@free-electrons.com; rich...@nod.at;
> cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek <mich...@xilinx.com>;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri <punn...@xilinx.com>
> Subject: Re: [PATCH v6 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote:
> > This patch adds the dts binding document for arasan nand flash
> > controller.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> > Acked-by: Rob Herring <r...@kernel.org>
> > ---
> > changes in v6:
> > - Removed num-cs property
> > - Separated nandchip from nand controller
> > changes in v5:
> > - None
> > Changes in v4:
> > - Added num-cs property
> > - Added clock support
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None
> > ---
> > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > 1 file changed, 38 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > new file mode 100644
> > index 000..dcbe7ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > @@ -0,0 +1,38 @@
> > +Arasan Nand Flash Controller with ONFI 3.1 support
>
> Arasan NAND Flash ...
>
> > +Required properties:
> > +- compatible: Should be "arasan,nfc-v3p10"
>
> This v3p10 looks like version 3 patchlevel 10, but shouldn't we have
> some fallback option which doesn't encode IP version in the compat
> string ?
>
This is a third-party IP and v3p10 is the version that we are using in our SOC.
Also this IP doesn’t have the IP version information in the register space to
read dynamically and having generic compatible name. So, any new versions
can be added through of_match_table with config data inside the driver.
> Also, shouldn't quirks be handled by DT props instead of effectively
> encoding them into the compatible string ?
>
I feel the above mentioned method will be more appropriate rather than defining
the quirks through DT properties.
I will fix all other comments
Regards,
Punnaiah
> > +- reg: Memory map for module access
> > +- interrupt-parent: Interrupt controller the interrupt is routed through
> > +- interrupts: Should contain the interrupt for the device
> > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
> > + (See clock bindings for details)
> > +- clocks: Clock phandles (see clock bindings for details)
> > +
> > +Optional properties:
> > +- arasan,has-mdma: Enables Dma support
>
> 'Enables DMA support' , with DMA in caps.
>
> > +for nand partition information please refer the below file
>
> For NAND ...
>
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + nand0: nand@ff10 {
> > + compatible = "arasan,nfc-v3p10"
> > + reg = <0x0 0xff10 0x1000>;
> > + clock-name = "clk_sys", "clk_flash"
> > + clocks = <_clk _clk>;
> > + interrupt-parent = <>;
> > + interrupts = <0 14 4>;
> > + arasan,has-mdma;
> > + #address-cells = <1>;
> > + #size-cells = <0>
> > +
> > + nand@0 {
> > + reg = <0>
> > + partition@0 {
> > + label = "filesystem";
> > + reg = <0x0 0x0 0x100>;
> > + };
> > + (...)
> > + };
> > + };
> >
>
>
> --
> Best regards,
> Marek Vasut
RE: [PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
Hi Marek,
Thanks for the review.
> -Original Message-
> From: Marek Vasut [mailto:marek.va...@gmail.com]
> Sent: Monday, December 05, 2016 9:56 AM
> To: Punnaiah Choudary Kalluri ;
> dw...@infradead.org; computersforpe...@gmail.com;
> boris.brezil...@free-electrons.com; rich...@nod.at;
> cyrille.pitc...@atmel.com; robh...@kernel.org; mark.rutl...@arm.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> devicet...@vger.kernel.org; Michal Simek ;
> kalluripunnaiahchoud...@gmail.com; kpc...@gmail.com; Punnaiah
> Choudary Kalluri
> Subject: Re: [PATCH v6 1/2] mtd: arasan: Add device tree binding
> documentation
>
> On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote:
> > This patch adds the dts binding document for arasan nand flash
> > controller.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri
> > Acked-by: Rob Herring
> > ---
> > changes in v6:
> > - Removed num-cs property
> > - Separated nandchip from nand controller
> > changes in v5:
> > - None
> > Changes in v4:
> > - Added num-cs property
> > - Added clock support
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None
> > ---
> > .../devicetree/bindings/mtd/arasan_nfc.txt | 38
> ++
> > 1 file changed, 38 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > new file mode 100644
> > index 000..dcbe7ad
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
> > @@ -0,0 +1,38 @@
> > +Arasan Nand Flash Controller with ONFI 3.1 support
>
> Arasan NAND Flash ...
>
> > +Required properties:
> > +- compatible: Should be "arasan,nfc-v3p10"
>
> This v3p10 looks like version 3 patchlevel 10, but shouldn't we have
> some fallback option which doesn't encode IP version in the compat
> string ?
>
This is a third-party IP and v3p10 is the version that we are using in our SOC.
Also this IP doesn’t have the IP version information in the register space to
read dynamically and having generic compatible name. So, any new versions
can be added through of_match_table with config data inside the driver.
> Also, shouldn't quirks be handled by DT props instead of effectively
> encoding them into the compatible string ?
>
I feel the above mentioned method will be more appropriate rather than defining
the quirks through DT properties.
I will fix all other comments
Regards,
Punnaiah
> > +- reg: Memory map for module access
> > +- interrupt-parent: Interrupt controller the interrupt is routed through
> > +- interrupts: Should contain the interrupt for the device
> > +- clock-name: List of input clocks - "clk_sys", "clk_flash"
> > + (See clock bindings for details)
> > +- clocks: Clock phandles (see clock bindings for details)
> > +
> > +Optional properties:
> > +- arasan,has-mdma: Enables Dma support
>
> 'Enables DMA support' , with DMA in caps.
>
> > +for nand partition information please refer the below file
>
> For NAND ...
>
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + nand0: nand@ff10 {
> > + compatible = "arasan,nfc-v3p10"
> > + reg = <0x0 0xff10 0x1000>;
> > + clock-name = "clk_sys", "clk_flash"
> > + clocks = <_clk _clk>;
> > + interrupt-parent = <>;
> > + interrupts = <0 14 4>;
> > + arasan,has-mdma;
> > + #address-cells = <1>;
> > + #size-cells = <0>
> > +
> > + nand@0 {
> > + reg = <0>
> > + partition@0 {
> > + label = "filesystem";
> > + reg = <0x0 0x0 0x100>;
> > + };
> > + (...)
> > + };
> > + };
> >
>
>
> --
> Best regards,
> Marek Vasut
[PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
Acked-by: Rob Herring <r...@kernel.org>
---
changes in v6:
- Removed num-cs property
- Separated nandchip from nand controller
changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..dcbe7ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,38 @@
+Arasan Nand Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables Dma support
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ #address-cells = <1>;
+ #size-cells = <0>
+
+ nand@0 {
+ reg = <0>
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
+ };
--
2.7.4
[PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri
Acked-by: Rob Herring
---
changes in v6:
- Removed num-cs property
- Separated nandchip from nand controller
changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..dcbe7ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,38 @@
+Arasan Nand Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables Dma support
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ #address-cells = <1>;
+ #size-cells = <0>
+
+ nand@0 {
+ reg = <0>
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
+ };
--
2.7.4
[PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash Controller
Added the basic driver for Arasan Nand Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> --- Chnages in v6: - Addressed most of the Brian and Boris comments - Separated the nandchip from the nand controller - Removed the ecc lookup table from driver - Now use framework nand waitfunction and readoob - Fixed the compiler warning - Adapted the new frameowrk changes related to ecc and ooblayout - Disabled the clocks after the nand_reelase - Now using only one completion object - Boris suggessions like adapting cmd_ctrl and rework on read/write byte are not implemented and i will patch them later - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will implement later once the basic driver is mainlined. Changes in v5: - Renamed the driver filei as arasan_nand.c - Fixed all comments relaqted coding style - Fixed comments related to propagating the errors - Modified the anfc_write_page_hwecc as per the write_page prototype Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report erro --- drivers/mtd/nand/Kconfig | 8 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/arasan_nand.c | 974 + 3 files changed, 983 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 7b7a887..e831f4e 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -569,4 +569,12 @@ config MTD_NAND_MTK Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + depends on HAS_IOMEM + depends on HAS_DMA + help + Enables the driver for the Arasan Nand Flash controller on + Zynq UltraScale+ MPSoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index cafde6f..44b8b00 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -58,5 +58,6 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c new file mode 100644 index 000..6b0670e --- /dev/null +++ b/drivers/mtd/nand/arasan_nand.c @@ -0,0 +1,974 @@ +/* + * Arasan Nand Flash Controller Driver + * + * Copyright (C) 2014 - 2015 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nand" +#define EVNT_TIMEOUT 1000 +#define STATUS_TIMEOUT 2000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_REG 0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENABLE BIT(31) +#define DMA_EN_MASKGENMASK(27, 26) +#define DMA_ENABLE 0x2 +#define DMA_EN_SHIFT 26 +#define REG_PAGE_SIZE_MASK GENMASK(25, 23) +#define REG_PAGE_SIZE_SHIFT
[PATCH v6 2/2] mtd: nand: Add support for Arasan Nand Flash Controller
Added the basic driver for Arasan Nand Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri --- Chnages in v6: - Addressed most of the Brian and Boris comments - Separated the nandchip from the nand controller - Removed the ecc lookup table from driver - Now use framework nand waitfunction and readoob - Fixed the compiler warning - Adapted the new frameowrk changes related to ecc and ooblayout - Disabled the clocks after the nand_reelase - Now using only one completion object - Boris suggessions like adapting cmd_ctrl and rework on read/write byte are not implemented and i will patch them later - Also check_erased_ecc_chunk for erase and check for is_vmalloc_addr will implement later once the basic driver is mainlined. Changes in v5: - Renamed the driver filei as arasan_nand.c - Fixed all comments relaqted coding style - Fixed comments related to propagating the errors - Modified the anfc_write_page_hwecc as per the write_page prototype Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report erro --- drivers/mtd/nand/Kconfig | 8 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/arasan_nand.c | 974 + 3 files changed, 983 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 7b7a887..e831f4e 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -569,4 +569,12 @@ config MTD_NAND_MTK Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + depends on HAS_IOMEM + depends on HAS_DMA + help + Enables the driver for the Arasan Nand Flash controller on + Zynq UltraScale+ MPSoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index cafde6f..44b8b00 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -58,5 +58,6 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c new file mode 100644 index 000..6b0670e --- /dev/null +++ b/drivers/mtd/nand/arasan_nand.c @@ -0,0 +1,974 @@ +/* + * Arasan Nand Flash Controller Driver + * + * Copyright (C) 2014 - 2015 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nand" +#define EVNT_TIMEOUT 1000 +#define STATUS_TIMEOUT 2000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_REG 0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENABLE BIT(31) +#define DMA_EN_MASKGENMASK(27, 26) +#define DMA_ENABLE 0x2 +#define DMA_EN_SHIFT 26 +#define REG_PAGE_SIZE_MASK GENMASK(25, 23) +#define REG_PAGE_SIZE_SHIFT23 +#define REG_PAGE
RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Sent: Tuesday, October 25, 2016 4:30 AM > To: Punnaiah Choudary Kalluri <punn...@xilinx.com> > Cc: Boris Brezillon <boris.brezil...@free-electrons.com>; Punnaiah Choudary > Kalluri <punn...@xilinx.com>; mark.rutl...@arm.com; linux- > m...@lists.infradead.org; michal.si...@xilinx.com; ezequiel.garcia@free- > electrons.com; linux-kernel@vger.kernel.org; r...@landley.net; > ga...@codeaurora.org; Khoronzhuk, Ivan <ivan.khoronz...@ti.com>; > computersforpe...@gmail.com; dw...@infradead.org > Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand > interface > > [cc list trimmed] > > On Sun, Oct 23, 2016 at 05:37:42PM +0530, punnaiah choudary kalluri wrote: > > Hi Boris and Jason, > > > > I am doing rework on these patches to accommodate recent changes with > > respect to ooblayout. Also some of the comments that i have received > > from Boris as part of the arasan nand controller upstream patches will > > apply to this driver. So, i will be releasing the next set of patches for > > this > > driver soon and request your time for reviewing those patches. > > I have hacked the v7 patchset enough to work on 4.8 and hacked it some > more to work on my hardware. The driver appears to be in no better > shape than the 3.12 out-of-tree Xilinx release I was using previously.. The driver in Xilinx tree works with 4.6 kernel and adopted the required Changes (may release in 1-2 weeks). Still it need some rework, now a days I am seeing many requests from different people for this driver and some of Them are using different version of IP as you know this IP has four variants and Xilinx is using the pl353 variant. Let's wait for the next series of patches and Get the patches tested with others as well along with the review comments. Regards, Punnaiah > I've attached the ugly, ugly patch I made, it may save you some time > when preparing v8. > > Commentary: > 1) nand_chip already includes mtd_info, no reason for a second one in > the pl353_nand_info struct. The standard accessors mtd_to_nand/etc > should be used instead of priv > 2) I hacked out all the ECC stuff from the driver since I don't use > it and it was broken.. Obviously some has to come back, but fixing > other things on this list first will make that much easier and better.. > 3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure > outdated copies of the core routines and should not exist in a > driver. This needs to be fixed so nand_scan_tail sets them. > This seems to be a side effect of #9 ? > 4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work, > and doesn't work without ONFI (see patch for possible fix). The > driver should probably use the same scheme the core code uses.. > But this is all a problem because of #10 > 5) The driver assumes alignment of the iomap, needs to use + not | > when constructing the address. (yes, this blows up on my system) > 6) Driver unconditionally sets timing to ONFI mode 0 (slow!) > Maybe timing should be common code driven by DT.. > 7) Driver unconditionally selects a BBT format, and an ECC layout > (neither match what my system uses, but I guess that is a core mtd > issue these days :/) > 8) Driver unconditionally forces a chip-delay (wrong for my > system) maybe this should be common code driven by DT.. > 9) This buisness with pl353_nand_ecc_init and the > special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff > is just horrid. I'd expect that is a big NAK. > > The driver needs to implement read_buf *properly* so the core > routines can be used instead of trying to 'fix' the call sites > to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff. > 10) pl353_nand_cmd_function is a wonky copy of nand_command_lp, > maybe > this driver should use cmd_ctrl, or the core code should be > refactored some more.. > > Jason > > diff --git a/drivers/mtd/nand/pl353_nand.c > b/drivers/mtd/nand/pl353_nand.c > index 7e3993931f75..63a8d8c008e3 100644 > --- a/drivers/mtd/nand/pl353_nand.c > +++ b/drivers/mtd/nand/pl353_nand.c > @@ -26,7 +26,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -56,7 +55,6 @@ > #define PL353_NAND_ECC_LAST BIT(ECC_LAST_SHIFT) /* Set > ECC_Last */ > #define PL353_NAND_CLEAR_CS BIT(CLEAR_CS_SHIFT) /* Clear chip > select */ > > -#define ONDIE_ECC_FEATURE_ADDR 0x90 > #define PL353_NAND_ECC_BUSY_TIMEOUT (1 * HZ) > #define PL353_NAND_DEV_BUSY_TIMEOUT (1 * HZ) > #define P
RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
> -Original Message-
> From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
> Sent: Tuesday, October 25, 2016 4:30 AM
> To: Punnaiah Choudary Kalluri
> Cc: Boris Brezillon ; Punnaiah Choudary
> Kalluri ; mark.rutl...@arm.com; linux-
> m...@lists.infradead.org; michal.si...@xilinx.com; ezequiel.garcia@free-
> electrons.com; linux-kernel@vger.kernel.org; r...@landley.net;
> ga...@codeaurora.org; Khoronzhuk, Ivan ;
> computersforpe...@gmail.com; dw...@infradead.org
> Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand
> interface
>
> [cc list trimmed]
>
> On Sun, Oct 23, 2016 at 05:37:42PM +0530, punnaiah choudary kalluri wrote:
> > Hi Boris and Jason,
> >
> > I am doing rework on these patches to accommodate recent changes with
> > respect to ooblayout. Also some of the comments that i have received
> > from Boris as part of the arasan nand controller upstream patches will
> > apply to this driver. So, i will be releasing the next set of patches for
> > this
> > driver soon and request your time for reviewing those patches.
>
> I have hacked the v7 patchset enough to work on 4.8 and hacked it some
> more to work on my hardware. The driver appears to be in no better
> shape than the 3.12 out-of-tree Xilinx release I was using previously..
The driver in Xilinx tree works with 4.6 kernel and adopted the required
Changes (may release in 1-2 weeks). Still it need some rework, now a days
I am seeing many requests from different people for this driver and some of
Them are using different version of IP as you know this IP has four variants and
Xilinx is using the pl353 variant. Let's wait for the next series of patches
and
Get the patches tested with others as well along with the review comments.
Regards,
Punnaiah
> I've attached the ugly, ugly patch I made, it may save you some time
> when preparing v8.
>
> Commentary:
> 1) nand_chip already includes mtd_info, no reason for a second one in
> the pl353_nand_info struct. The standard accessors mtd_to_nand/etc
> should be used instead of priv
> 2) I hacked out all the ECC stuff from the driver since I don't use
> it and it was broken.. Obviously some has to come back, but fixing
> other things on this list first will make that much easier and better..
> 3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are pure
> outdated copies of the core routines and should not exist in a
> driver. This needs to be fixed so nand_scan_tail sets them.
> This seems to be a side effect of #9 ?
> 4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work,
> and doesn't work without ONFI (see patch for possible fix). The
> driver should probably use the same scheme the core code uses..
> But this is all a problem because of #10
> 5) The driver assumes alignment of the iomap, needs to use + not |
> when constructing the address. (yes, this blows up on my system)
> 6) Driver unconditionally sets timing to ONFI mode 0 (slow!)
> Maybe timing should be common code driven by DT..
> 7) Driver unconditionally selects a BBT format, and an ECC layout
> (neither match what my system uses, but I guess that is a core mtd
> issue these days :/)
> 8) Driver unconditionally forces a chip-delay (wrong for my
> system) maybe this should be common code driven by DT..
> 9) This buisness with pl353_nand_ecc_init and the
> special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff
> is just horrid. I'd expect that is a big NAK.
>
> The driver needs to implement read_buf *properly* so the core
> routines can be used instead of trying to 'fix' the call sites
> to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff.
> 10) pl353_nand_cmd_function is a wonky copy of nand_command_lp,
> maybe
> this driver should use cmd_ctrl, or the core code should be
> refactored some more..
>
> Jason
>
> diff --git a/drivers/mtd/nand/pl353_nand.c
> b/drivers/mtd/nand/pl353_nand.c
> index 7e3993931f75..63a8d8c008e3 100644
> --- a/drivers/mtd/nand/pl353_nand.c
> +++ b/drivers/mtd/nand/pl353_nand.c
> @@ -26,7 +26,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -56,7 +55,6 @@
> #define PL353_NAND_ECC_LAST BIT(ECC_LAST_SHIFT) /* Set
> ECC_Last */
> #define PL353_NAND_CLEAR_CS BIT(CLEAR_CS_SHIFT) /* Clear chip
> select */
>
> -#define ONDIE_ECC_FEATURE_ADDR 0x90
> #define PL353_NAND_ECC_BUSY_TIMEOUT (1 * HZ)
> #define PL353_NAND_DEV_BUSY_TIMEOUT (1 * HZ)
> #define PL353_NAND_LAST_TRANSFER_LENGTH 4
> @@ -88,11 +86,9 @@ struct pl353_nand_command_format {
> */
> st
RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Sent: Tuesday, October 25, 2016 10:16 AM > To: Punnaiah Choudary Kalluri <punn...@xilinx.com> > Cc: Boris Brezillon <boris.brezil...@free-electrons.com>; > mark.rutl...@arm.com; linux-...@lists.infradead.org; > michal.si...@xilinx.com; ezequiel.gar...@free-electrons.com; linux- > ker...@vger.kernel.org; r...@landley.net; ga...@codeaurora.org; > computersforpe...@gmail.com; dw...@infradead.org > Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand > interface > > On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote: > > > > I have hacked the v7 patchset enough to work on 4.8 and hacked it some > > > more to work on my hardware. The driver appears to be in no better > > > shape than the 3.12 out-of-tree Xilinx release I was using previously.. > > > > The driver in Xilinx tree works with 4.6 kernel and adopted the > > required > > I mean, the driver from the 3.12 Xilinx tree that I last looked > at years ago. This is at v7 now and is still needs lots of work, I did > some fixing, including making parts of it work on 4.8. > You can copy it out of the patch I sent you. > > > Changes (may release in 1-2 weeks). Still it need some rework, now a days > > I am seeing many requests from different people for this driver and some > of > > Them are using different version of IP as you know this IP has four variants > and > > Xilinx is using the pl353 variant. > > Well, I am using Xilinx Zynq hardware and care about making that > configuration actually work. This is the last driver I require to use > Zynq with mainline. > Sure. > It clearly needs more work than just forward porting to 4.8, so please > let me know if you are able to tackle this. I didn't say that I am forwarding the patch working with 4.8. I said We made changes to driver compatible for 4.6 and working on driver rework, Most of your comments also part of that. > > > Let's wait for the next series of patches and Get the patches tested > > with others as well along with the review comments. > > You now have 10 review comments from me, please respond to all of them > in > your v8 patchset - no sense in continuing to drag this out. > See above. > Please cc me on future series. Ok. Regards, Punnaiah > > Jason > > > Regards, > > Punnaiah > > > I've attached the ugly, ugly patch I made, it may save you some time > > > when preparing v8. > > > > > > Commentary: > > > 1) nand_chip already includes mtd_info, no reason for a second one in > > > the pl353_nand_info struct. The standard accessors mtd_to_nand/etc > > > should be used instead of priv > > > 2) I hacked out all the ECC stuff from the driver since I don't use > > > it and it was broken.. Obviously some has to come back, but fixing > > > other things on this list first will make that much easier and > > > better.. > > > 3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are > pure > > > outdated copies of the core routines and should not exist in a > > > driver. This needs to be fixed so nand_scan_tail sets them. > > > This seems to be a side effect of #9 ? > > > 4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work, > > > and doesn't work without ONFI (see patch for possible fix). The > > > driver should probably use the same scheme the core code uses.. > > > But this is all a problem because of #10 > > > 5) The driver assumes alignment of the iomap, needs to use + not | > > > when constructing the address. (yes, this blows up on my system) > > > 6) Driver unconditionally sets timing to ONFI mode 0 (slow!) > > > Maybe timing should be common code driven by DT.. > > > 7) Driver unconditionally selects a BBT format, and an ECC layout > > > (neither match what my system uses, but I guess that is a core mtd > > > issue these days :/) > > > 8) Driver unconditionally forces a chip-delay (wrong for my > > > system) maybe this should be common code driven by DT.. > > > 9) This buisness with pl353_nand_ecc_init and the > > > special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff > > > is just horrid. I'd expect that is a big NAK. > > > > > > The driver needs to implement read_buf *properly* so the core > > > routines can be used instead of trying to 'fix' the call sites > > > to do the PL353_NAND_LAST_TRANSFER_LENGTH st
RE: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
> -Original Message- > From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com] > Sent: Tuesday, October 25, 2016 10:16 AM > To: Punnaiah Choudary Kalluri > Cc: Boris Brezillon ; > mark.rutl...@arm.com; linux-...@lists.infradead.org; > michal.si...@xilinx.com; ezequiel.gar...@free-electrons.com; linux- > ker...@vger.kernel.org; r...@landley.net; ga...@codeaurora.org; > computersforpe...@gmail.com; dw...@infradead.org > Subject: Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand > interface > > On Tue, Oct 25, 2016 at 03:58:49AM +, Punnaiah Choudary Kalluri wrote: > > > > I have hacked the v7 patchset enough to work on 4.8 and hacked it some > > > more to work on my hardware. The driver appears to be in no better > > > shape than the 3.12 out-of-tree Xilinx release I was using previously.. > > > > The driver in Xilinx tree works with 4.6 kernel and adopted the > > required > > I mean, the driver from the 3.12 Xilinx tree that I last looked > at years ago. This is at v7 now and is still needs lots of work, I did > some fixing, including making parts of it work on 4.8. > You can copy it out of the patch I sent you. > > > Changes (may release in 1-2 weeks). Still it need some rework, now a days > > I am seeing many requests from different people for this driver and some > of > > Them are using different version of IP as you know this IP has four variants > and > > Xilinx is using the pl353 variant. > > Well, I am using Xilinx Zynq hardware and care about making that > configuration actually work. This is the last driver I require to use > Zynq with mainline. > Sure. > It clearly needs more work than just forward porting to 4.8, so please > let me know if you are able to tackle this. I didn't say that I am forwarding the patch working with 4.8. I said We made changes to driver compatible for 4.6 and working on driver rework, Most of your comments also part of that. > > > Let's wait for the next series of patches and Get the patches tested > > with others as well along with the review comments. > > You now have 10 review comments from me, please respond to all of them > in > your v8 patchset - no sense in continuing to drag this out. > See above. > Please cc me on future series. Ok. Regards, Punnaiah > > Jason > > > Regards, > > Punnaiah > > > I've attached the ugly, ugly patch I made, it may save you some time > > > when preparing v8. > > > > > > Commentary: > > > 1) nand_chip already includes mtd_info, no reason for a second one in > > > the pl353_nand_info struct. The standard accessors mtd_to_nand/etc > > > should be used instead of priv > > > 2) I hacked out all the ECC stuff from the driver since I don't use > > > it and it was broken.. Obviously some has to come back, but fixing > > > other things on this list first will make that much easier and > > > better.. > > > 3) pl353_nand_write_page_swecc/pl353_nand_read_page_swecc are > pure > > > outdated copies of the core routines and should not exist in a > > > driver. This needs to be fixed so nand_scan_tail sets them. > > > This seems to be a side effect of #9 ? > > > 4) The hacky stuff to detect 2 vs 3 address cycle NAND doesn't work, > > > and doesn't work without ONFI (see patch for possible fix). The > > > driver should probably use the same scheme the core code uses.. > > > But this is all a problem because of #10 > > > 5) The driver assumes alignment of the iomap, needs to use + not | > > > when constructing the address. (yes, this blows up on my system) > > > 6) Driver unconditionally sets timing to ONFI mode 0 (slow!) > > > Maybe timing should be common code driven by DT.. > > > 7) Driver unconditionally selects a BBT format, and an ECC layout > > > (neither match what my system uses, but I guess that is a core mtd > > > issue these days :/) > > > 8) Driver unconditionally forces a chip-delay (wrong for my > > > system) maybe this should be common code driven by DT.. > > > 9) This buisness with pl353_nand_ecc_init and the > > > special functions to do PL353_NAND_LAST_TRANSFER_LENGTH stuff > > > is just horrid. I'd expect that is a big NAK. > > > > > > The driver needs to implement read_buf *properly* so the core > > > routines can be used instead of trying to 'fix' the call sites > > > to do the PL353_NAND_LAST_TRANSFER_LENGTH stuff. > > > 10) pl353_nand_cmd_function is a wonky copy of nand_command_lp, > > > maybe > > > this driver should use cmd_ctrl, or the core code should be > > > refactored some more.. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Boris and Jason, I am doing rework on these patches to accommodate recent changes with respect to ooblayout. Also some of the comments that i have received from Boris as part of the arasan nand controller upstream patches will apply to this driver. So, i will be releasing the next set of patches for this driver soon and request your time for reviewing those patches. for now, please ignore these patches. Regards, Punnaiah On Sat, Oct 22, 2016 at 3:16 AM, Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > On Fri, 21 Oct 2016 14:33:22 -0600 > Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > >> On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote: >> > Add driver for arm pl353 static memory controller nand interface with >> > HW ECC support. This controller is used in xilinx zynq soc for interfacing >> > the nand flash memory. >> > >> > Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> >> > Changes in v7: >> > - Currently not implemented the memclk rate adjustments. I will >> >look into this later and once the basic driver is accepted. >> > - Fixed GPL licence ident >> > Changes in v6: >> > - Fixed the checkpatch.pl reported warnings >> > - Using the address cycles information from the onfi param page >> >earlier it is hardcoded to 5 in driver >> > Changes in v5: >> > - Configure the nand timing parameters as per the onfi spec >> > Changes in v4: >> > - Updated the driver to sync with pl353_smc driver APIs >> > Changes in v3: >> > - implemented the proper error codes >> > - further breakdown this patch to multiple sets >> > - added the controller and driver details to Documentation section >> > - updated the licenece to GPLv2 >> > - reorganized the pl353_nand_ecc_init function >> > Changes in v2: >> > - use "depends on" rather than "select" option in kconfig >> > - remove unused variable parts >> > - remove dummy helper and use writel_relaxed directly >> >> What is the status of getting this driver merged? I am interested in >> this driver and can provide some help if there are still TODO items. > > I'll try to review it next week. > >> >> At the very least I will test it, is there something newer than v7 out >> there? >> >> Regards, >> Jason >> >> __ >> Linux MTD discussion mailing list >> http://lists.infradead.org/mailman/listinfo/linux-mtd/ >
Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
Hi Boris and Jason, I am doing rework on these patches to accommodate recent changes with respect to ooblayout. Also some of the comments that i have received from Boris as part of the arasan nand controller upstream patches will apply to this driver. So, i will be releasing the next set of patches for this driver soon and request your time for reviewing those patches. for now, please ignore these patches. Regards, Punnaiah On Sat, Oct 22, 2016 at 3:16 AM, Boris Brezillon wrote: > On Fri, 21 Oct 2016 14:33:22 -0600 > Jason Gunthorpe wrote: > >> On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote: >> > Add driver for arm pl353 static memory controller nand interface with >> > HW ECC support. This controller is used in xilinx zynq soc for interfacing >> > the nand flash memory. >> > >> > Signed-off-by: Punnaiah Choudary Kalluri >> > Changes in v7: >> > - Currently not implemented the memclk rate adjustments. I will >> >look into this later and once the basic driver is accepted. >> > - Fixed GPL licence ident >> > Changes in v6: >> > - Fixed the checkpatch.pl reported warnings >> > - Using the address cycles information from the onfi param page >> >earlier it is hardcoded to 5 in driver >> > Changes in v5: >> > - Configure the nand timing parameters as per the onfi spec >> > Changes in v4: >> > - Updated the driver to sync with pl353_smc driver APIs >> > Changes in v3: >> > - implemented the proper error codes >> > - further breakdown this patch to multiple sets >> > - added the controller and driver details to Documentation section >> > - updated the licenece to GPLv2 >> > - reorganized the pl353_nand_ecc_init function >> > Changes in v2: >> > - use "depends on" rather than "select" option in kconfig >> > - remove unused variable parts >> > - remove dummy helper and use writel_relaxed directly >> >> What is the status of getting this driver merged? I am interested in >> this driver and can provide some help if there are still TODO items. > > I'll try to review it next week. > >> >> At the very least I will test it, is there something newer than v7 out >> there? >> >> Regards, >> Jason >> >> __ >> Linux MTD discussion mailing list >> http://lists.infradead.org/mailman/listinfo/linux-mtd/ >
RE: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC
Hi Nicolas, 1588 implementation in cadence GEM IP we have in Zynq Ultascale+ MPSoC is Different to the one in Zynq SOC. In earlier version, all timestamp values will be stored in registers and there is no specific Mechanism to distinguish the received ethernet frame that contains time stamp information Other than parsing the frame for PTP packet type. We have basic implementation for earlier version in our out of tree driver, which is going to be deprecated Soon. You could also check the below driver for 1588 support. https://gitenterprise.xilinx.com/Linux/linux-xlnx/blob/master/drivers/net/ethernet/xilinx/xilinx_emacps.c Regards, Punnaiah > -Original Message- > From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com] > Sent: Tuesday, August 09, 2016 10:10 PM > To: Harini Katakam <harinikatakamli...@gmail.com>; Harini Katakam > <hari...@xilinx.com>; Andrei Pistirica <andrei.pistir...@microchip.com> > Cc: da...@davemloft.net; Boris Brezillon <boris.brezillon@free- > electrons.com>; alexandre.bell...@free-electrons.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; > devicet...@vger.kernel.org; Punnaiah Choudary Kalluri > <punn...@xilinx.com>; Michal Simek <mich...@xilinx.com>; Anirudha > Sarangi <anir...@xilinx.com> > Subject: Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq > Ultrascale+ MPSoC > > Le 21/09/2015 à 19:49, Harini Katakam a écrit : > > On Fri, Sep 11, 2015 at 1:27 PM, Harini Katakam > > <harini.kata...@xilinx.com> wrote: > >> Cadence GEM in Zynq Ultrascale+ MPSoC supports 1588 and provides a > >> 102 bit time counter with 48 bits for seconds, 30 bits for nsecs and > >> 24 bits for sub-nsecs. The timestamp is made available to the SW through > >> registers as well as (more precisely) through upper two words in > >> an extended BD. > >> > >> This patch does the following: > >> - Adds MACB_CAPS_TSU in zynqmp_config. > >> - Registers to ptp clock framework (after checking for timestamp support > in > >> IP and capability in config). > >> - TX BD and RX BD control registers are written to populate timestamp in > >> extended BD words. > >> - Timer initialization is done by writing time of day to the timer counter. > >> - ns increment register is programmed as NS_PER_SEC/TSU_CLK. > >> For a 24 bit subns precision, the subns increment equals > >> remainder of (NS_PER_SEC/TSU_CLK) * (2^24). > >> TSU (Time stamp unit) clock is obtained by the driver from devicetree. > >> - HW time stamp capabilities are advertised via ethtool and macb ioctl is > >> updated accordingly. > >> - For all PTP event frames, nanoseconds and the lower 5 bits of seconds > are > >> obtained from the BD. This offers a precise timestamp. The upper bits > >> (which dont vary between consecutive packets) are obtained from the > >> TX/RX PTP event/PEER registers. The timestamp obtained thus is > updated > >> in skb for upper layers to access. > >> - The drivers register functions with ptp to perform time and frequency > >> adjustment. > >> - Time adjustment is done by writing to the 1558_ADJUST register. > >> The controller will read the delta in this register and update the timer > >> counter register. Alternatively, for large time offset adjustments, > >> the driver reads the secs and nsecs counter values, adds/subtracts the > >> delta and updates the timer counter. In order to be as precise as > possible, > >> nsecs counter is read again if secs has incremented during the counter > read. > >> - Frequency adjustment is not directly supported by this IP. > >> addend is the initial value ns increment and similarly addendesub. > >> The ppb (parts per billion) provided is used as > >> ns_incr = addend +/- (ppb/rate). > >> Similarly the remainder of the above is used to populate subns > increment. > >> In case the ppb requested is negative AND subns adjustment greater > than > >> the addendsub, ns_incr is reduced by 1 and subns_incr is adjusted in > >> positive accordingly. > >> > >> Signed-off-by: Harini Katakam <hari...@xilinx.com>: > >> --- > >> drivers/net/ethernet/cadence/macb.c | 372 > ++- > >> drivers/net/ethernet/cadence/macb.h | 64 ++ > >> 2 files changed, 428 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/net/ethernet/cadence/macb.c > b/drivers/net/ethernet/cadence/macb.c > >> index bb2932c..b531008 100644 > >> -
RE: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC
Hi Nicolas, 1588 implementation in cadence GEM IP we have in Zynq Ultascale+ MPSoC is Different to the one in Zynq SOC. In earlier version, all timestamp values will be stored in registers and there is no specific Mechanism to distinguish the received ethernet frame that contains time stamp information Other than parsing the frame for PTP packet type. We have basic implementation for earlier version in our out of tree driver, which is going to be deprecated Soon. You could also check the below driver for 1588 support. https://gitenterprise.xilinx.com/Linux/linux-xlnx/blob/master/drivers/net/ethernet/xilinx/xilinx_emacps.c Regards, Punnaiah > -Original Message- > From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com] > Sent: Tuesday, August 09, 2016 10:10 PM > To: Harini Katakam ; Harini Katakam > ; Andrei Pistirica > Cc: da...@davemloft.net; Boris Brezillon electrons.com>; alexandre.bell...@free-electrons.com; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; > devicet...@vger.kernel.org; Punnaiah Choudary Kalluri > ; Michal Simek ; Anirudha > Sarangi > Subject: Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq > Ultrascale+ MPSoC > > Le 21/09/2015 à 19:49, Harini Katakam a écrit : > > On Fri, Sep 11, 2015 at 1:27 PM, Harini Katakam > > wrote: > >> Cadence GEM in Zynq Ultrascale+ MPSoC supports 1588 and provides a > >> 102 bit time counter with 48 bits for seconds, 30 bits for nsecs and > >> 24 bits for sub-nsecs. The timestamp is made available to the SW through > >> registers as well as (more precisely) through upper two words in > >> an extended BD. > >> > >> This patch does the following: > >> - Adds MACB_CAPS_TSU in zynqmp_config. > >> - Registers to ptp clock framework (after checking for timestamp support > in > >> IP and capability in config). > >> - TX BD and RX BD control registers are written to populate timestamp in > >> extended BD words. > >> - Timer initialization is done by writing time of day to the timer counter. > >> - ns increment register is programmed as NS_PER_SEC/TSU_CLK. > >> For a 24 bit subns precision, the subns increment equals > >> remainder of (NS_PER_SEC/TSU_CLK) * (2^24). > >> TSU (Time stamp unit) clock is obtained by the driver from devicetree. > >> - HW time stamp capabilities are advertised via ethtool and macb ioctl is > >> updated accordingly. > >> - For all PTP event frames, nanoseconds and the lower 5 bits of seconds > are > >> obtained from the BD. This offers a precise timestamp. The upper bits > >> (which dont vary between consecutive packets) are obtained from the > >> TX/RX PTP event/PEER registers. The timestamp obtained thus is > updated > >> in skb for upper layers to access. > >> - The drivers register functions with ptp to perform time and frequency > >> adjustment. > >> - Time adjustment is done by writing to the 1558_ADJUST register. > >> The controller will read the delta in this register and update the timer > >> counter register. Alternatively, for large time offset adjustments, > >> the driver reads the secs and nsecs counter values, adds/subtracts the > >> delta and updates the timer counter. In order to be as precise as > possible, > >> nsecs counter is read again if secs has incremented during the counter > read. > >> - Frequency adjustment is not directly supported by this IP. > >> addend is the initial value ns increment and similarly addendesub. > >> The ppb (parts per billion) provided is used as > >> ns_incr = addend +/- (ppb/rate). > >> Similarly the remainder of the above is used to populate subns > increment. > >> In case the ppb requested is negative AND subns adjustment greater > than > >> the addendsub, ns_incr is reduced by 1 and subns_incr is adjusted in > >> positive accordingly. > >> > >> Signed-off-by: Harini Katakam : > >> --- > >> drivers/net/ethernet/cadence/macb.c | 372 > ++- > >> drivers/net/ethernet/cadence/macb.h | 64 ++ > >> 2 files changed, 428 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/net/ethernet/cadence/macb.c > b/drivers/net/ethernet/cadence/macb.c > >> index bb2932c..b531008 100644 > >> --- a/drivers/net/ethernet/cadence/macb.c > >> +++ b/drivers/net/ethernet/cadence/macb.c > >> @@ -30,6 +30,8 @@ > >> #include > >> #include > > [..] > > >> + unsigned intns_incr; >
RE: [RFC PATCH v4 2/2] net: phy: Add gmiitorgmii converter support
Hi Kedar,
> -Original Message-
> From: Kedareswara rao Appana [mailto:appana.durga@xilinx.com]
> Sent: Monday, August 08, 2016 12:45 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> <mich...@xilinx.com>; Soren Brinkmann <sor...@xilinx.com>; Appana
> Durga Kedareswara Rao <appa...@xilinx.com>; f.faine...@gmail.com;
> and...@lunn.ch; Punnaiah Choudary Kalluri <punn...@xilinx.com>;
> Anirudha Sarangi <anir...@xilinx.com>
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: [RFC PATCH v4 2/2] net: phy: Add gmiitorgmii converter support
>
> This patch adds support for gmiitorgmii converter.
>
> The GMII to RGMII IP core provides the Reduced Gigabit Media
> Independent Interface (RGMII) between Ethernet physical media
> Devices and the Gigabit Ethernet controller. This core can
> Switch dynamically between the three different speed modes of
> Operation by configuring the converter register through mdio write.
>
> MDIO interface is used to set operating speed of Ethernet MAC.
>
> Signed-off-by: Kedareswara rao Appana <appa...@xilinx.com>
> ---
> Thanks a lot Andrew for your inputs.
> Changes for v4:
> --> Updated phydev speed for all 3 speeds as suggested by zhuyj.
> Changes for v3:
> --> Updated the driver as suggested by Andrew.
> Changes for v2:
> --> Passed struct xphy pointer directly to the fix_mac_speed
> API as suggested by the Florian.
> --> Added checks for the phy-node fail case as suggested
> by the Florian
>
> +
> +#define XILINX_GMII2RGMII_REG0x10
> +#define BMCR_SPEED10 0x00
Move this macro to mii.h
> +
> +struct gmii2rgmii {
> + struct phy_device *phy_dev;
> + struct phy_driver *phy_drv;
> + struct phy_driver conv_phy_drv;
> + int addr;
> +};
> +
> +static int xgmiitorgmii_read_status(struct phy_device *phydev)
> +{
> + struct gmii2rgmii *priv = (struct gmii2rgmii *)phydev->priv;
> + u16 val = 0;
> +
> + priv->phy_drv->read_status(phydev);
> +
> + val = mdiobus_read(phydev->mdio.bus, priv->addr,
> XILINX_GMII2RGMII_REG);
> +
Since its read and then modify, you should mask the speed field
With zero and then write new value.
> + switch (phydev->speed) {
> + case SPEED_1000:
> + val |= BMCR_SPEED1000;
> + case SPEED_100:
> + val |= BMCR_SPEED100;
> + case SPEED_10:
> + val |= BMCR_SPEED10;
> + }
> +
> + mdiobus_write(phydev->mdio.bus, priv->addr,
> XILINX_GMII2RGMII_REG, val);
> +
> + return 0;
> +}
> +
> +int xgmiitorgmii_probe(struct mdio_device *mdiodev)
> +{
> + struct device *dev = >dev;
> + struct device_node *np = dev->of_node, *phy_node;
> + struct gmii2rgmii *priv;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + phy_node = of_parse_phandle(np, "phy-handle", 0);
> + if (IS_ERR(phy_node)) {
> + dev_err(dev, "Couldn't parse phy-handle\n");
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + priv->phy_dev = of_phy_find_device(phy_node);
> + if (!priv->phy_dev) {
> + ret = -EPROBE_DEFER;
> + dev_info(dev, "Couldn't find phydev\n");
> + goto out;
> + }
> +
> + priv->addr = mdiodev->addr;
> + priv->phy_drv = priv->phy_dev->drv;
> + memcpy(>conv_phy_drv, priv->phy_dev->drv,
> +sizeof(struct phy_driver));
> + priv->conv_phy_drv.read_status = xgmiitorgmii_read_status;
> + priv->phy_dev->priv = priv;
> + priv->phy_dev->drv = >conv_phy_drv;
> +
> + return 0;
> +out:
> + return ret;
Since there is no resource cleaning here, you could consider
Return from this function in above conditions and avoid goto here.
Regards,
Punnaiah
> +}
> +
> +static const struct of_device_id xgmiitorgmii_of_match[] = {
> + { .compatible = "xlnx,gmii-to-rgmii-1.0" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, xgmiitorgmii_of_match);
> +
> +static struct mdio_driver xgmiitorgmii_driver = {
> + .probe = xgmiitorgmii_probe,
> + .mdiodrv.driver = {
> + .name = "xgmiitorgmii",
> + .of_match_table = xgmiitorgmii_of_match,
> + },
> +};
> +
> +static int __init xgmiitorgmii_init(void)
> +{
> + return mdio_driver_register(_driver);
> +}
> +module_init(xgmiitorgmii_init);
> +
> +static void __exit xgmiitorgmii_cleanup(void)
> +{
> + mdio_driver_unregister(_driver);
> +}
> +module_exit(xgmiitorgmii_cleanup);
> +
> +MODULE_DESCRIPTION("Xilinx GMII2RGMII converter driver");
> +MODULE_LICENSE("GPL");
> --
> 2.1.2
RE: [RFC PATCH v4 2/2] net: phy: Add gmiitorgmii converter support
Hi Kedar,
> -Original Message-
> From: Kedareswara rao Appana [mailto:appana.durga@xilinx.com]
> Sent: Monday, August 08, 2016 12:45 PM
> To: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; Soren Brinkmann ; Appana
> Durga Kedareswara Rao ; f.faine...@gmail.com;
> and...@lunn.ch; Punnaiah Choudary Kalluri ;
> Anirudha Sarangi
> Cc: devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org
> Subject: [RFC PATCH v4 2/2] net: phy: Add gmiitorgmii converter support
>
> This patch adds support for gmiitorgmii converter.
>
> The GMII to RGMII IP core provides the Reduced Gigabit Media
> Independent Interface (RGMII) between Ethernet physical media
> Devices and the Gigabit Ethernet controller. This core can
> Switch dynamically between the three different speed modes of
> Operation by configuring the converter register through mdio write.
>
> MDIO interface is used to set operating speed of Ethernet MAC.
>
> Signed-off-by: Kedareswara rao Appana
> ---
> Thanks a lot Andrew for your inputs.
> Changes for v4:
> --> Updated phydev speed for all 3 speeds as suggested by zhuyj.
> Changes for v3:
> --> Updated the driver as suggested by Andrew.
> Changes for v2:
> --> Passed struct xphy pointer directly to the fix_mac_speed
> API as suggested by the Florian.
> --> Added checks for the phy-node fail case as suggested
> by the Florian
>
> +
> +#define XILINX_GMII2RGMII_REG0x10
> +#define BMCR_SPEED10 0x00
Move this macro to mii.h
> +
> +struct gmii2rgmii {
> + struct phy_device *phy_dev;
> + struct phy_driver *phy_drv;
> + struct phy_driver conv_phy_drv;
> + int addr;
> +};
> +
> +static int xgmiitorgmii_read_status(struct phy_device *phydev)
> +{
> + struct gmii2rgmii *priv = (struct gmii2rgmii *)phydev->priv;
> + u16 val = 0;
> +
> + priv->phy_drv->read_status(phydev);
> +
> + val = mdiobus_read(phydev->mdio.bus, priv->addr,
> XILINX_GMII2RGMII_REG);
> +
Since its read and then modify, you should mask the speed field
With zero and then write new value.
> + switch (phydev->speed) {
> + case SPEED_1000:
> + val |= BMCR_SPEED1000;
> + case SPEED_100:
> + val |= BMCR_SPEED100;
> + case SPEED_10:
> + val |= BMCR_SPEED10;
> + }
> +
> + mdiobus_write(phydev->mdio.bus, priv->addr,
> XILINX_GMII2RGMII_REG, val);
> +
> + return 0;
> +}
> +
> +int xgmiitorgmii_probe(struct mdio_device *mdiodev)
> +{
> + struct device *dev = >dev;
> + struct device_node *np = dev->of_node, *phy_node;
> + struct gmii2rgmii *priv;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + phy_node = of_parse_phandle(np, "phy-handle", 0);
> + if (IS_ERR(phy_node)) {
> + dev_err(dev, "Couldn't parse phy-handle\n");
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + priv->phy_dev = of_phy_find_device(phy_node);
> + if (!priv->phy_dev) {
> + ret = -EPROBE_DEFER;
> + dev_info(dev, "Couldn't find phydev\n");
> + goto out;
> + }
> +
> + priv->addr = mdiodev->addr;
> + priv->phy_drv = priv->phy_dev->drv;
> + memcpy(>conv_phy_drv, priv->phy_dev->drv,
> +sizeof(struct phy_driver));
> + priv->conv_phy_drv.read_status = xgmiitorgmii_read_status;
> + priv->phy_dev->priv = priv;
> + priv->phy_dev->drv = >conv_phy_drv;
> +
> + return 0;
> +out:
> + return ret;
Since there is no resource cleaning here, you could consider
Return from this function in above conditions and avoid goto here.
Regards,
Punnaiah
> +}
> +
> +static const struct of_device_id xgmiitorgmii_of_match[] = {
> + { .compatible = "xlnx,gmii-to-rgmii-1.0" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, xgmiitorgmii_of_match);
> +
> +static struct mdio_driver xgmiitorgmii_driver = {
> + .probe = xgmiitorgmii_probe,
> + .mdiodrv.driver = {
> + .name = "xgmiitorgmii",
> + .of_match_table = xgmiitorgmii_of_match,
> + },
> +};
> +
> +static int __init xgmiitorgmii_init(void)
> +{
> + return mdio_driver_register(_driver);
> +}
> +module_init(xgmiitorgmii_init);
> +
> +static void __exit xgmiitorgmii_cleanup(void)
> +{
> + mdio_driver_unregister(_driver);
> +}
> +module_exit(xgmiitorgmii_cleanup);
> +
> +MODULE_DESCRIPTION("Xilinx GMII2RGMII converter driver");
> +MODULE_LICENSE("GPL");
> --
> 2.1.2
RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Wednesday, July 06, 2016 7:51 PM
> To: Punnaiah Choudary Kalluri <punn...@xilinx.com>
> Cc: Appana Durga Kedareswara Rao <appa...@xilinx.com>;
> robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> <mich...@xilinx.com>; Soren Brinkmann <sor...@xilinx.com>;
> nicolas.fe...@atmel.com; f.faine...@gmail.com; Anirudha Sarangi
> <anir...@xilinx.com>; Harini Katakam <hari...@xilinx.com>;
> net...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx
> gmiitorgmii converter device tree binding documentation
>
> > > Hi Kedareswara
> > >
> > > So looking at the device tree, you have the gmiitorgmii as an mdio
> > > device. It will get probed as an mdio device, and from that you know
> > > the address on the bus. However, your driver does not actually do
> > > this. xilinx_gmii2rgmii.c is just a library of two functions, and does
> > > not use any of this device tree information. You device tree binding
> > > is completely bogus.
> > >
> > > What i think is a much more logical structure, and fits the hardware,
> > > which is what DT is all about, is to make your driver an mdio driver.
> > > Also, have a phy-handle pointing to the PHY in the gmii_to_rgmii node.
> > > You then no longer need the exported gmii2rgmii_phyprobe() function.
> > >
> > > Next, you want gmiitorgmii driver to register a phy. The MAC driver
> > > can then look this up using phy-handle:
> > >
> > >mdio {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > phy: ethernet-phy@0 {
> > > reg = <0>;
> > > };
> > >
> > > gmii_to_rgmii: gmii-to-rgmii@8 {
> > > compatible = "xlnx,gmiitorgmii";
> > > reg = <8>;
> > > phy-handle = <>;
> > > };
> > >};
> >
> >
> > Thanks for your inputs initially we too thought the similar implementation
> > But the GMII2RGMII converter contains only one register and it is
> > not compatible to the standard ethernet MII interface. Also it doesn't have
> > a standard VID and PID registers So, during the mdio bus scan, this device
> will
> > not appear.
>
> Hi Punnaiah
>
> Use missed some subtlety in my description. I did not call the
> GMII2RGMII a PHY device, i called it an MDIO device. These are
> different things. Go look at the MDIO subsystem to figure out the
> difference.
>
Hi Andrew
Got it. Thanks.
Punnaiah
> Andrew
RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Wednesday, July 06, 2016 7:51 PM
> To: Punnaiah Choudary Kalluri
> Cc: Appana Durga Kedareswara Rao ;
> robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; Soren Brinkmann ;
> nicolas.fe...@atmel.com; f.faine...@gmail.com; Anirudha Sarangi
> ; Harini Katakam ;
> net...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx
> gmiitorgmii converter device tree binding documentation
>
> > > Hi Kedareswara
> > >
> > > So looking at the device tree, you have the gmiitorgmii as an mdio
> > > device. It will get probed as an mdio device, and from that you know
> > > the address on the bus. However, your driver does not actually do
> > > this. xilinx_gmii2rgmii.c is just a library of two functions, and does
> > > not use any of this device tree information. You device tree binding
> > > is completely bogus.
> > >
> > > What i think is a much more logical structure, and fits the hardware,
> > > which is what DT is all about, is to make your driver an mdio driver.
> > > Also, have a phy-handle pointing to the PHY in the gmii_to_rgmii node.
> > > You then no longer need the exported gmii2rgmii_phyprobe() function.
> > >
> > > Next, you want gmiitorgmii driver to register a phy. The MAC driver
> > > can then look this up using phy-handle:
> > >
> > >mdio {
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > >
> > > phy: ethernet-phy@0 {
> > > reg = <0>;
> > > };
> > >
> > > gmii_to_rgmii: gmii-to-rgmii@8 {
> > > compatible = "xlnx,gmiitorgmii";
> > > reg = <8>;
> > > phy-handle = <>;
> > > };
> > >};
> >
> >
> > Thanks for your inputs initially we too thought the similar implementation
> > But the GMII2RGMII converter contains only one register and it is
> > not compatible to the standard ethernet MII interface. Also it doesn't have
> > a standard VID and PID registers So, during the mdio bus scan, this device
> will
> > not appear.
>
> Hi Punnaiah
>
> Use missed some subtlety in my description. I did not call the
> GMII2RGMII a PHY device, i called it an MDIO device. These are
> different things. Go look at the MDIO subsystem to figure out the
> difference.
>
Hi Andrew
Got it. Thanks.
Punnaiah
> Andrew
RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, July 04, 2016 7:35 PM
> To: Appana Durga Kedareswara Rao <appa...@xilinx.com>
> Cc: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> <mich...@xilinx.com>; Soren Brinkmann <sor...@xilinx.com>; Punnaiah
> Choudary Kalluri <punn...@xilinx.com>; nicolas.fe...@atmel.com;
> f.faine...@gmail.com; Anirudha Sarangi <anir...@xilinx.com>; Harini
> Katakam <hari...@xilinx.com>; net...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Appana Durga Kedareswara Rao
> <appa...@xilinx.com>
> Subject: Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx
> gmiitorgmii converter device tree binding documentation
>
> On Mon, Jul 04, 2016 at 02:34:41PM +0530, Kedareswara rao Appana wrote:
> > Device-tree binding documentation for xilinx gmiitorgmii converter.
> >
> > Signed-off-by: Kedareswara rao Appana <appa...@xilinx.com>
> > ---
> > Changes for v2:
> > --> New patch.
> >
> > .../devicetree/bindings/net/xilinx_gmii2rgmii.txt | 31
> ++
> > 1 file changed, 31 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> > new file mode 100644
> > index 000..d11e259
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> > @@ -0,0 +1,31 @@
> > +* XILINX GMIITORGMII Converter Driver
> > +
> > +The Gigabit Media Independent Interface (GMII) to Reduced Gigabit
> Media
> > +Independent Interface (RGMII) core provides the RGMII between RGMII-
> compliant
> > +Ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
> > +This core can be used in all three modes of operation(10/100/1000 Mb/s).
> > +The Management Data Input/Output (MDIO) interface is used to
> configure the
> > +Speed of operation. This core can switch dynamically between the three
> > +Different speed modes by configuring the conveter register through mdio
> write.
> > +
> > +The MDIO is a bus to which the PHY devices are connected. For each
> > +device that exists on this bus, a child node should be created. See
> > +the definition of the PHY node in booting-without-of.txt for an example
> > +of how to define a PHY.
> > +
> > +Required properties:
> > + - compatible : Should be "xlnx,gmiitorgmii"
> > + - reg : The ID number for the phy, usually a small integer
> > +
> > +Example:
> > + mdio {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > + ethernet-phy@0 {
> > + ..
> > + };
> > +gmii_to_rgmii: gmii_to_rgmii@8 {
> > +compatible = "xlnx,gmiitorgmii";
> > +reg = <8>;
> > +};
> > +};
>
> Hi Kedareswara
>
> So looking at the device tree, you have the gmiitorgmii as an mdio
> device. It will get probed as an mdio device, and from that you know
> the address on the bus. However, your driver does not actually do
> this. xilinx_gmii2rgmii.c is just a library of two functions, and does
> not use any of this device tree information. You device tree binding
> is completely bogus.
>
> What i think is a much more logical structure, and fits the hardware,
> which is what DT is all about, is to make your driver an mdio driver.
> Also, have a phy-handle pointing to the PHY in the gmii_to_rgmii node.
> You then no longer need the exported gmii2rgmii_phyprobe() function.
>
> Next, you want gmiitorgmii driver to register a phy. The MAC driver
> can then look this up using phy-handle:
>
>mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> phy: ethernet-phy@0 {
> reg = <0>;
> };
>
> gmii_to_rgmii: gmii-to-rgmii@8 {
> compatible = "xlnx,gmiitorgmii";
> reg = <8>;
> phy-handle = <>;
> };
>};
Thanks for your inputs initially we too thought the similar implementation
But the GMII2RGMII converter contains only one register and it is
not compatible to the standard ethernet MII interface. Also
RE: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, July 04, 2016 7:35 PM
> To: Appana Durga Kedareswara Rao
> Cc: robh...@kernel.org; mark.rutl...@arm.com; Michal Simek
> ; Soren Brinkmann ; Punnaiah
> Choudary Kalluri ; nicolas.fe...@atmel.com;
> f.faine...@gmail.com; Anirudha Sarangi ; Harini
> Katakam ; net...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Appana Durga Kedareswara Rao
>
> Subject: Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx
> gmiitorgmii converter device tree binding documentation
>
> On Mon, Jul 04, 2016 at 02:34:41PM +0530, Kedareswara rao Appana wrote:
> > Device-tree binding documentation for xilinx gmiitorgmii converter.
> >
> > Signed-off-by: Kedareswara rao Appana
> > ---
> > Changes for v2:
> > --> New patch.
> >
> > .../devicetree/bindings/net/xilinx_gmii2rgmii.txt | 31
> ++
> > 1 file changed, 31 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> > new file mode 100644
> > index 000..d11e259
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/xilinx_gmii2rgmii.txt
> > @@ -0,0 +1,31 @@
> > +* XILINX GMIITORGMII Converter Driver
> > +
> > +The Gigabit Media Independent Interface (GMII) to Reduced Gigabit
> Media
> > +Independent Interface (RGMII) core provides the RGMII between RGMII-
> compliant
> > +Ethernet physical media devices (PHY) and the Gigabit Ethernet controller.
> > +This core can be used in all three modes of operation(10/100/1000 Mb/s).
> > +The Management Data Input/Output (MDIO) interface is used to
> configure the
> > +Speed of operation. This core can switch dynamically between the three
> > +Different speed modes by configuring the conveter register through mdio
> write.
> > +
> > +The MDIO is a bus to which the PHY devices are connected. For each
> > +device that exists on this bus, a child node should be created. See
> > +the definition of the PHY node in booting-without-of.txt for an example
> > +of how to define a PHY.
> > +
> > +Required properties:
> > + - compatible : Should be "xlnx,gmiitorgmii"
> > + - reg : The ID number for the phy, usually a small integer
> > +
> > +Example:
> > + mdio {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > + ethernet-phy@0 {
> > + ..
> > + };
> > +gmii_to_rgmii: gmii_to_rgmii@8 {
> > +compatible = "xlnx,gmiitorgmii";
> > +reg = <8>;
> > +};
> > +};
>
> Hi Kedareswara
>
> So looking at the device tree, you have the gmiitorgmii as an mdio
> device. It will get probed as an mdio device, and from that you know
> the address on the bus. However, your driver does not actually do
> this. xilinx_gmii2rgmii.c is just a library of two functions, and does
> not use any of this device tree information. You device tree binding
> is completely bogus.
>
> What i think is a much more logical structure, and fits the hardware,
> which is what DT is all about, is to make your driver an mdio driver.
> Also, have a phy-handle pointing to the PHY in the gmii_to_rgmii node.
> You then no longer need the exported gmii2rgmii_phyprobe() function.
>
> Next, you want gmiitorgmii driver to register a phy. The MAC driver
> can then look this up using phy-handle:
>
>mdio {
> #address-cells = <1>;
> #size-cells = <0>;
>
> phy: ethernet-phy@0 {
> reg = <0>;
> };
>
> gmii_to_rgmii: gmii-to-rgmii@8 {
> compatible = "xlnx,gmiitorgmii";
> reg = <8>;
> phy-handle = <>;
> };
>};
Thanks for your inputs initially we too thought the similar implementation
But the GMII2RGMII converter contains only one register and it is
not compatible to the standard ethernet MII interface. Also it doesn't have
a standard VID and PID registers So, during the mdio bus scan, this device will
not appear. When macb driver calls the gmii2rgmii phy-handle through
phy_connect_direct/of_phy_connect, thes
RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
> -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Tuesday, June 28, 2016 9:45 AM > To: Punnaiah Choudary Kalluri <punn...@xilinx.com> > Cc: Appana Durga Kedareswara Rao <appa...@xilinx.com>; > robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek > <mich...@xilinx.com>; Soren Brinkmann <sor...@xilinx.com>; > dan.j.willi...@intel.com; moritz.fisc...@ettus.com; > laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth > Vemula <svem...@xilinx.com>; Anirudha Sarangi <anir...@xilinx.com>; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; dmaeng...@vger.kernel.org > Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine > driver support > > On Tue, Jun 21, 2016 at 05:29:42PM +, Punnaiah Choudary Kalluri wrote: > > > > Ok agree with you for the scenario that I have mentioned above. > > > > Other simple dma mode feature that I missed to explain is configuring the > > Dma descriptors. It provides a register interface for configuring the dma > transaction. > > So, no need to maintain the descriptors in memory and it will be useful for > the system > > that are in crunch of memory. > > And why are these not coming out in the first place, which makes me think it > is fishy! > > Do you mean programming DMA descriptors to hardware and you can use > registers instead of memory? > Yes. > > > > How do you want us to handle this case? > > > > > > Okay I am convince now this is not right approach. Please remove this > > > custom interface and then implement slave for required slave scenarios! > > > > > > > Assume controller is having 8 channels and four of them are used for slave > > Dma and others are for memcpy. > > Controller didn't have the per channel priority control but providing the > rate control > > Mechanism. > > How does the use of few for memcpy and few for slave change things? IMO > it > doesn't, you program the channel accordingly > > > > > So, I need some interface for configuring the rate control per channel at > run time irrespective > > Of whether the channel is allocated for slave dma or memcpy dma. > > why? > This is to prioritize the channel over other channels at runtime. Also, if the slave device doesn't have a flow control implemented, Then rate control is one mechanism for controlling the transactions Between the source and destination. > > Is it wrong having the configurable dma parameters for dma memcpy > operation? We are exposing the > > Hw capabilities to the user for better dma transaction management. > > For memcpy yes. Memcpy is a generic case where people do not do driver > specific stuff. So I tend ot push back on that.. > Ok. Then we will consider using slave dma if the memcpy requires custom Settings (the settings might be for debug purpose or there is real hw design that mandates changes in default optimized settings). > For slave, existing APIs allow you to program the additional parameters.. > FWIW, rate control is a generic parameter which if you justify enough can be > added to dma_slave_config > As said above, rate control will be helpful for the controller that doesn't have Per channel priority option and also cases where slave device/controller that Doesn't have Flow control implemented. Thanks, Punnaiah > Thanks > -- > ~Vinod
RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
> -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Tuesday, June 28, 2016 9:45 AM > To: Punnaiah Choudary Kalluri > Cc: Appana Durga Kedareswara Rao ; > robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek > ; Soren Brinkmann ; > dan.j.willi...@intel.com; moritz.fisc...@ettus.com; > laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth > Vemula ; Anirudha Sarangi ; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; dmaeng...@vger.kernel.org > Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine > driver support > > On Tue, Jun 21, 2016 at 05:29:42PM +, Punnaiah Choudary Kalluri wrote: > > > > Ok agree with you for the scenario that I have mentioned above. > > > > Other simple dma mode feature that I missed to explain is configuring the > > Dma descriptors. It provides a register interface for configuring the dma > transaction. > > So, no need to maintain the descriptors in memory and it will be useful for > the system > > that are in crunch of memory. > > And why are these not coming out in the first place, which makes me think it > is fishy! > > Do you mean programming DMA descriptors to hardware and you can use > registers instead of memory? > Yes. > > > > How do you want us to handle this case? > > > > > > Okay I am convince now this is not right approach. Please remove this > > > custom interface and then implement slave for required slave scenarios! > > > > > > > Assume controller is having 8 channels and four of them are used for slave > > Dma and others are for memcpy. > > Controller didn't have the per channel priority control but providing the > rate control > > Mechanism. > > How does the use of few for memcpy and few for slave change things? IMO > it > doesn't, you program the channel accordingly > > > > > So, I need some interface for configuring the rate control per channel at > run time irrespective > > Of whether the channel is allocated for slave dma or memcpy dma. > > why? > This is to prioritize the channel over other channels at runtime. Also, if the slave device doesn't have a flow control implemented, Then rate control is one mechanism for controlling the transactions Between the source and destination. > > Is it wrong having the configurable dma parameters for dma memcpy > operation? We are exposing the > > Hw capabilities to the user for better dma transaction management. > > For memcpy yes. Memcpy is a generic case where people do not do driver > specific stuff. So I tend ot push back on that.. > Ok. Then we will consider using slave dma if the memcpy requires custom Settings (the settings might be for debug purpose or there is real hw design that mandates changes in default optimized settings). > For slave, existing APIs allow you to program the additional parameters.. > FWIW, rate control is a generic parameter which if you justify enough can be > added to dma_slave_config > As said above, rate control will be helpful for the controller that doesn't have Per channel priority option and also cases where slave device/controller that Doesn't have Flow control implemented. Thanks, Punnaiah > Thanks > -- > ~Vinod
RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
Hi Vinod, > -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Tuesday, June 21, 2016 9:11 PM > To: Appana Durga Kedareswara Rao <appa...@xilinx.com> > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek > <mich...@xilinx.com>; Soren Brinkmann <sor...@xilinx.com>; > dan.j.willi...@intel.com; moritz.fisc...@ettus.com; > laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth > Vemula <svem...@xilinx.com>; Anirudha Sarangi <anir...@xilinx.com>; > Punnaiah Choudary Kalluri <punn...@xilinx.com>; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; dmaeng...@vger.kernel.org > Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine > driver support > > On Thu, Jun 16, 2016 at 07:19:38AM +, Appana Durga Kedareswara Rao > wrote: > > Hi Vinod, > > > > Thanks for the review... > > > > > > > > On Tue, Jun 14, 2016 at 08:18:09AM +, Appana Durga Kedareswara > Rao > > > wrote: > > > > > > Yes it is HW capability. It can be either in simple mode or SG > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > device-tree But as per lars and your suggestion moved it as runtime > config > > > parameters. > > > > > > > > > > If sg mode is available why would anyone _not_ want it? > > > > > > > > > > I do not think there is point to have this > > > > > > > > You mean always keep the device in SG mode and provide an option > For > > > > simple dma mode if user want to use simple DMA mode?? > > > > > > Yes, why would anyone want to use single if sg is available? > > If you have sg mode always enabled, but sg_list is size 1, that its > essentially a single > True. As we said, simple mode ha few additional features like write only And read only dma. So, if user want then here is the provision. > Btw SPI is a slave case, not a memcpy! > Correct. We are working on slave dma support and will patch to this driver. > > > > There are few features that are available in the simple DMA mode > won't > > > > Available in SG mode like write only DMA , read only DMA mode etc... > > > > > > Can you explain what these are, how they are used by clients? > > > > Currently it is not implemented but there are cases like, > > > > We want to initialize the some region with known value, then write only > dma helps > > We want to read dummy data from the fifo, then read only dma helps. > > Read will be another transfer, perhpas sg lnegth = 1 > In sg case, both source and destination locations need to be configured. In simple dma and read-only mode, only source address is required. Simple Dma just read the data from source location and discard that data. It will save Unnecessary write to destination here. > > Best case is SPI fifo. > > Nope > Why? > > > > > > > > > > > > > + chan->config.ratectrl = cfg->ratectrl; > > > > > > > > + chan->config.src_issue = cfg->src_issue; > > > > > > > > + chan->config.src_burst_len = cfg->src_burst_len; > > > > > > > > + chan->config.dst_burst_len = cfg->dst_burst_len; > > > > > > > > > > > > > > can you describe these parameters? > > > > > > ratectl: > > > > > > Rate control can be independently enabled per channel. When rate > > > > > > control is enabled, the DMA channel uses the rate control count to > > > > > > schedule > > > > > successive data read transactions. > > > > > > > > > > And how is this used by client? > > > > > > > > When rate control is enabled, ZDMA channel uses the rate control > count > > > > To schedule successive data read transactions I mean kind of flow > > > > control to schedule Transactions at fixed intervals instead of pumping > > > > the transfers without delay or whenever bus is available > > > > > > > > Rate control count register definition (11:0): > > > > Scheduling interval for SRC AXI transaction, only used if rate control > > > > is enabled > > > > > > Okay, why would anyone want transactions at fixed interval. We are > talking > > > about DMA, so please
RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
Hi Vinod, > -Original Message- > From: Vinod Koul [mailto:vinod.k...@intel.com] > Sent: Tuesday, June 21, 2016 9:11 PM > To: Appana Durga Kedareswara Rao > Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; > ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek > ; Soren Brinkmann ; > dan.j.willi...@intel.com; moritz.fisc...@ettus.com; > laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth > Vemula ; Anirudha Sarangi ; > Punnaiah Choudary Kalluri ; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; dmaeng...@vger.kernel.org > Subject: Re: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine > driver support > > On Thu, Jun 16, 2016 at 07:19:38AM +, Appana Durga Kedareswara Rao > wrote: > > Hi Vinod, > > > > Thanks for the review... > > > > > > > > On Tue, Jun 14, 2016 at 08:18:09AM +, Appana Durga Kedareswara > Rao > > > wrote: > > > > > > Yes it is HW capability. It can be either in simple mode or SG > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > device-tree But as per lars and your suggestion moved it as runtime > config > > > parameters. > > > > > > > > > > If sg mode is available why would anyone _not_ want it? > > > > > > > > > > I do not think there is point to have this > > > > > > > > You mean always keep the device in SG mode and provide an option > For > > > > simple dma mode if user want to use simple DMA mode?? > > > > > > Yes, why would anyone want to use single if sg is available? > > If you have sg mode always enabled, but sg_list is size 1, that its > essentially a single > True. As we said, simple mode ha few additional features like write only And read only dma. So, if user want then here is the provision. > Btw SPI is a slave case, not a memcpy! > Correct. We are working on slave dma support and will patch to this driver. > > > > There are few features that are available in the simple DMA mode > won't > > > > Available in SG mode like write only DMA , read only DMA mode etc... > > > > > > Can you explain what these are, how they are used by clients? > > > > Currently it is not implemented but there are cases like, > > > > We want to initialize the some region with known value, then write only > dma helps > > We want to read dummy data from the fifo, then read only dma helps. > > Read will be another transfer, perhpas sg lnegth = 1 > In sg case, both source and destination locations need to be configured. In simple dma and read-only mode, only source address is required. Simple Dma just read the data from source location and discard that data. It will save Unnecessary write to destination here. > > Best case is SPI fifo. > > Nope > Why? > > > > > > > > > > > > > + chan->config.ratectrl = cfg->ratectrl; > > > > > > > > + chan->config.src_issue = cfg->src_issue; > > > > > > > > + chan->config.src_burst_len = cfg->src_burst_len; > > > > > > > > + chan->config.dst_burst_len = cfg->dst_burst_len; > > > > > > > > > > > > > > can you describe these parameters? > > > > > > ratectl: > > > > > > Rate control can be independently enabled per channel. When rate > > > > > > control is enabled, the DMA channel uses the rate control count to > > > > > > schedule > > > > > successive data read transactions. > > > > > > > > > > And how is this used by client? > > > > > > > > When rate control is enabled, ZDMA channel uses the rate control > count > > > > To schedule successive data read transactions I mean kind of flow > > > > control to schedule Transactions at fixed intervals instead of pumping > > > > the transfers without delay or whenever bus is available > > > > > > > > Rate control count register definition (11:0): > > > > Scheduling interval for SRC AXI transaction, only used if rate control > > > > is enabled > > > > > > Okay, why would anyone want transactions at fixed interval. We are > talking > > > about DMA, so please give me transfers without delay or whenever bus > is > > > available! > > > > Could be that there are certain IPs that requires dela
RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
> On Tue, Jun 21, 2016 at 04:19:38PM +0000, Punnaiah Choudary Kalluri wrote: > > > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > > > device-tree But as per lars and your suggestion moved it as > runtime > > > config > > > > > parameters. > > > > > > > > > > > > > > If sg mode is available why would anyone _not_ want it? > > > > > > > > > > > > > > I do not think there is point to have this > > > > > > > > > > > > You mean always keep the device in SG mode and provide an > option > > > For > > > > > > simple dma mode if user want to use simple DMA mode?? > > > > > > > > > > Yes, why would anyone want to use single if sg is available? > > > > > > If you have sg mode always enabled, but sg_list is size 1, that its > > > essentially a single > > > > > > > True. As we said, simple mode ha few additional features like write only > > And read only dma. So, if user want then here is the provision. > > > > > Btw SPI is a slave case, not a memcpy! > > > > > > > Correct. We are working on slave dma support and will patch to this driver. > > And in slave cases, you can use slave config to pass the values which are > required, so we dont need this custome interface! > Ok agree with you for the scenario that I have mentioned above. Other simple dma mode feature that I missed to explain is configuring the Dma descriptors. It provides a register interface for configuring the dma transaction. So, no need to maintain the descriptors in memory and it will be useful for the system that are in crunch of memory. How do you want us to handle this case? > > > > > > > > > > > > > > > > > > > > > > src_issue: > > > > > > > > Tells outstanding transaction on SRC. > > > > > > > > > > > > > > This should be read only then, right? > > > > > > > > > > > > It is a Read/Write register > > > > > > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq- > > > ultrascal > > > > > > e-registers.html By default it is configured for Max transactions. > > > > > > If user want to limit it they can limit it using this config option. > > > > > > > > > > And why would they want that? > > > > > > > > Could be that there are certain IPs that my not support burst operations > or > > > > May not support all burst lengths it will be helpful. > > > > Since IP is providing the feature, we are exploring it to the user. > > > > > > > > > > > > > > > > > Burst_len: > > > > > > > > Configures the burst length of the src and dst transfers... > > > > > > > > > > > > > > Hmmm, but you are on memcpy, so that should be programmed > for > > > > > throughput? > > > > > > > > > > > > Yes... > > > > > > > > > > So max burst lengths then, why would anyone configure lesser? > > > > > > > > Depends on the destination and source IPs. > > > > > > Not for memory copy > > > > > > > Depends on the system and how source and destination IPs are > interconnected. > > Sometimes there is a limitation from interconnection also. > > Also some flash controllers providing linear access to NAND or NOR > memories may > > Have limitation in burst length but still user can use memory copy with > desired burst > > Length. > > Some of those cases are treated as slave for obvious reasons. > > Please check existing solutions before inventing new ones. Everyone thinks > that their hardware and thereby driver is a novel case, but on closer > inspection that is usually not the case, different falvour yes, novel no! > > Okay I am convince now this is not right approach. Please remove this > custom interface and then implement slave for required slave scenarios! > Assume controller is having 8 channels and four of them are used for slave Dma and others are for memcpy. Controller didn't have the per channel priority control but providing the rate control Mechanism. So, I need some interface for configuring the rate control per channel at run time irrespective Of whether the channel is allocated for slave dma or memcpy dma. Is it wrong having the configurable dma parameters for dma memcpy operation? We are exposing the Hw capabilities to the user for better dma transaction management. > > > > > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > > Really! > My apologies :) Thanks, Punnaiah > > -- > ~Vinod
RE: [PATCH v10 2/2] dmaengine: Add Xilinx zynqmp dma engine driver support
> On Tue, Jun 21, 2016 at 04:19:38PM +0000, Punnaiah Choudary Kalluri wrote: > > > > > > > > mode Earlier In the driver this configuration is read from the > > > > > > > > device-tree But as per lars and your suggestion moved it as > runtime > > > config > > > > > parameters. > > > > > > > > > > > > > > If sg mode is available why would anyone _not_ want it? > > > > > > > > > > > > > > I do not think there is point to have this > > > > > > > > > > > > You mean always keep the device in SG mode and provide an > option > > > For > > > > > > simple dma mode if user want to use simple DMA mode?? > > > > > > > > > > Yes, why would anyone want to use single if sg is available? > > > > > > If you have sg mode always enabled, but sg_list is size 1, that its > > > essentially a single > > > > > > > True. As we said, simple mode ha few additional features like write only > > And read only dma. So, if user want then here is the provision. > > > > > Btw SPI is a slave case, not a memcpy! > > > > > > > Correct. We are working on slave dma support and will patch to this driver. > > And in slave cases, you can use slave config to pass the values which are > required, so we dont need this custome interface! > Ok agree with you for the scenario that I have mentioned above. Other simple dma mode feature that I missed to explain is configuring the Dma descriptors. It provides a register interface for configuring the dma transaction. So, no need to maintain the descriptors in memory and it will be useful for the system that are in crunch of memory. How do you want us to handle this case? > > > > > > > > > > > > > > > > > > > > > > src_issue: > > > > > > > > Tells outstanding transaction on SRC. > > > > > > > > > > > > > > This should be read only then, right? > > > > > > > > > > > > It is a Read/Write register > > > > > > http://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq- > > > ultrascal > > > > > > e-registers.html By default it is configured for Max transactions. > > > > > > If user want to limit it they can limit it using this config option. > > > > > > > > > > And why would they want that? > > > > > > > > Could be that there are certain IPs that my not support burst operations > or > > > > May not support all burst lengths it will be helpful. > > > > Since IP is providing the feature, we are exploring it to the user. > > > > > > > > > > > > > > > > > Burst_len: > > > > > > > > Configures the burst length of the src and dst transfers... > > > > > > > > > > > > > > Hmmm, but you are on memcpy, so that should be programmed > for > > > > > throughput? > > > > > > > > > > > > Yes... > > > > > > > > > > So max burst lengths then, why would anyone configure lesser? > > > > > > > > Depends on the destination and source IPs. > > > > > > Not for memory copy > > > > > > > Depends on the system and how source and destination IPs are > interconnected. > > Sometimes there is a limitation from interconnection also. > > Also some flash controllers providing linear access to NAND or NOR > memories may > > Have limitation in burst length but still user can use memory copy with > desired burst > > Length. > > Some of those cases are treated as slave for obvious reasons. > > Please check existing solutions before inventing new ones. Everyone thinks > that their hardware and thereby driver is a novel case, but on closer > inspection that is usually not the case, different falvour yes, novel no! > > Okay I am convince now this is not right approach. Please remove this > custom interface and then implement slave for required slave scenarios! > Assume controller is having 8 channels and four of them are used for slave Dma and others are for memcpy. Controller didn't have the per channel priority control but providing the rate control Mechanism. So, I need some interface for configuring the rate control per channel at run time irrespective Of whether the channel is allocated for slave dma or memcpy dma. Is it wrong having the configurable dma parameters for dma memcpy operation? We are exposing the Hw capabilities to the user for better dma transaction management. > > > > > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > > Really! > My apologies :) Thanks, Punnaiah > > -- > ~Vinod
Issue with ioremap
Hi,
We are using the pl353 smc controller for interfacing the nand in our zynq SOC.
The driver for this controller is currently under mainline review.
Recently we are moved to 4.4 kernel and observing issues with the driver.
while debug, found that the issue is with the virtual address returned from
the ioremap is not aligned to the physical address and causing nand
access failures.
the nand controller physical address starts at 0xE100 and the size is 16MB.
the ioremap function in 4.3 kernel returns the virtual address that is
aligned to the size
but not the case in 4.4 kernel.
this controller uses the bits [31:24] as base address and use rest all bits for
configuring adders cycles, chip select information. so it expects the
virtual address also
aligned to 0xFF00 otherwise the nand commands issued will fail.
with >= 4.4 kernel
0xf020-0xf1201000 16781312 devm_ioremap+0x3c/0x70 phys=e100 ioremap
with <= 4.3 kernel
0xf100-0xf2001000 16781312 devm_ioremap+0x38/0x68 phys=e100 ioremap
the below hack fixes the issue. but its not a proper fix and it just pointing
me the clue for this issue. so, any pointers and help to over come this issue ?
is there a way to do static mapping for the above requirement?
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8e3c9c5..fda58d6 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1340,9 +1340,13 @@ static struct vm_struct
*__get_vm_area_node(unsigned long size,
PAGE_SHIFT, IOREMAP_MAX_ORDER);
size = PAGE_ALIGN(size);
+ if (size == 0x100)
+ align = 0x100;
if (unlikely(!size))
return NULL;
+ printk(" size %x align %x\n", size, align);
+
area = kzalloc_node(sizeof(*area), gfp_mask & GFP_RECLAIM_MASK, node);
if (unlikely(!area))
return NULL;
Thanks,
Punnaiah
Issue with ioremap
Hi,
We are using the pl353 smc controller for interfacing the nand in our zynq SOC.
The driver for this controller is currently under mainline review.
Recently we are moved to 4.4 kernel and observing issues with the driver.
while debug, found that the issue is with the virtual address returned from
the ioremap is not aligned to the physical address and causing nand
access failures.
the nand controller physical address starts at 0xE100 and the size is 16MB.
the ioremap function in 4.3 kernel returns the virtual address that is
aligned to the size
but not the case in 4.4 kernel.
this controller uses the bits [31:24] as base address and use rest all bits for
configuring adders cycles, chip select information. so it expects the
virtual address also
aligned to 0xFF00 otherwise the nand commands issued will fail.
with >= 4.4 kernel
0xf020-0xf1201000 16781312 devm_ioremap+0x3c/0x70 phys=e100 ioremap
with <= 4.3 kernel
0xf100-0xf2001000 16781312 devm_ioremap+0x38/0x68 phys=e100 ioremap
the below hack fixes the issue. but its not a proper fix and it just pointing
me the clue for this issue. so, any pointers and help to over come this issue ?
is there a way to do static mapping for the above requirement?
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 8e3c9c5..fda58d6 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1340,9 +1340,13 @@ static struct vm_struct
*__get_vm_area_node(unsigned long size,
PAGE_SHIFT, IOREMAP_MAX_ORDER);
size = PAGE_ALIGN(size);
+ if (size == 0x100)
+ align = 0x100;
if (unlikely(!size))
return NULL;
+ printk(" size %x align %x\n", size, align);
+
area = kzalloc_node(sizeof(*area), gfp_mask & GFP_RECLAIM_MASK, node);
if (unlikely(!area))
return NULL;
Thanks,
Punnaiah
Re: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Hi Boris, On Tue, Mar 8, 2016 at 8:08 PM, Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > Hi Punnaiah, > > Sorry for the late review. > > On Sat, 21 Nov 2015 20:09:48 +0530 > Punnaiah Choudary Kalluri <punnaiah.choudary.kall...@xilinx.com> wrote: > >> Added the basic driver for Arasan Nand Flash Controller used in >> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit >> correction. >> >> Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> >> --- >> Changes in v5: >> - Renamed the driver filei as arasan_nand.c >> - Fixed all comments relaqted coding style >> - Fixed comments related to propagating the errors >> - Modified the anfc_write_page_hwecc as per the write_page >> prototype >> Changes in v4: >> - Added support for onfi timing mode configuration >> - Added clock suort >> - Added support for multiple chipselects >> Changes in v3: >> - Removed unused variables >> - Avoided busy loop and used jifies based implementation >> - Fixed compiler warnings "right shift count >= width of type" >> - Removed unneeded codei and improved error reporting >> - Added onfi version check to ensure reading the valid address cycles >> Changes in v2: >> - Added missing of.h to avoid kbuild system report error >> --- >> drivers/mtd/nand/Kconfig |6 + >> drivers/mtd/nand/Makefile |1 + >> drivers/mtd/nand/arasan_nand.c | 1010 >> >> 3 files changed, 1017 insertions(+) >> create mode 100644 drivers/mtd/nand/arasan_nand.c >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index 2896640..9c620fb 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -546,4 +546,10 @@ config MTD_NAND_HISI504 >> help >> Enables support for NAND controller on Hisilicon SoC Hip04. >> >> +config MTD_NAND_ARASAN >> + tristate "Support for Arasan Nand Flash controller" >> + help >> + Enables the driver for the Arasan Nand Flash controller on >> + Zynq UltraScale+ MPSoC. >> + >> endif # MTD_NAND >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index 2c7f014..3b993cb 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -55,5 +55,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)+= >> bcm47xxnflash/ >> obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o >> obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o >> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ >> +obj-$(CONFIG_MTD_NAND_ARASAN)+= arasan_nand.o >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o >> diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c >> new file mode 100644 >> index 000..e882e63 >> --- /dev/null >> +++ b/drivers/mtd/nand/arasan_nand.c >> @@ -0,0 +1,1010 @@ >> +/* >> + * Arasan Nand Flash Controller Driver >> + * >> + * Copyright (C) 2014 - 2015 Xilinx, Inc. >> + * >> + * This program is free software; you can redistribute it and/or modify it >> under >> + * the terms of the GNU General Public License version 2 as published by the >> + * Free Software Foundation; either version 2 of the License, or (at your >> + * option) any later version. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define DRIVER_NAME "arasan_nand" >> +#define EVNT_TIMEOUT 1000 >> +#define STATUS_TIMEOUT 2000 >> + >> +#define PKT_OFST 0x00 >> +#define MEM_ADDR1_OFST 0x04 >> +#define MEM_ADDR2_OFST 0x08 >> +#define CMD_OFST 0x0C >> +#define PROG_OFST0x10 >> +#define INTR_STS_EN_OFST 0x14 >> +#define INTR_SIG_EN_OFST 0x18 >> +#define INTR_STS_OFST0x1C >> +#define READY_STS_OFST 0x20 >> +#define DMA_ADDR1_OFST 0x24 >> +#define FLASH_STS_OFST 0x28 >> +#define DATA_PORT_OFST 0x30 >> +#define ECC_OFST 0x34 >> +#define ECC_ERR_CNT_OFST
Re: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Hi Boris, On Tue, Mar 8, 2016 at 8:08 PM, Boris Brezillon wrote: > Hi Punnaiah, > > Sorry for the late review. > > On Sat, 21 Nov 2015 20:09:48 +0530 > Punnaiah Choudary Kalluri wrote: > >> Added the basic driver for Arasan Nand Flash Controller used in >> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit >> correction. >> >> Signed-off-by: Punnaiah Choudary Kalluri >> --- >> Changes in v5: >> - Renamed the driver filei as arasan_nand.c >> - Fixed all comments relaqted coding style >> - Fixed comments related to propagating the errors >> - Modified the anfc_write_page_hwecc as per the write_page >> prototype >> Changes in v4: >> - Added support for onfi timing mode configuration >> - Added clock suort >> - Added support for multiple chipselects >> Changes in v3: >> - Removed unused variables >> - Avoided busy loop and used jifies based implementation >> - Fixed compiler warnings "right shift count >= width of type" >> - Removed unneeded codei and improved error reporting >> - Added onfi version check to ensure reading the valid address cycles >> Changes in v2: >> - Added missing of.h to avoid kbuild system report error >> --- >> drivers/mtd/nand/Kconfig |6 + >> drivers/mtd/nand/Makefile |1 + >> drivers/mtd/nand/arasan_nand.c | 1010 >> >> 3 files changed, 1017 insertions(+) >> create mode 100644 drivers/mtd/nand/arasan_nand.c >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index 2896640..9c620fb 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -546,4 +546,10 @@ config MTD_NAND_HISI504 >> help >> Enables support for NAND controller on Hisilicon SoC Hip04. >> >> +config MTD_NAND_ARASAN >> + tristate "Support for Arasan Nand Flash controller" >> + help >> + Enables the driver for the Arasan Nand Flash controller on >> + Zynq UltraScale+ MPSoC. >> + >> endif # MTD_NAND >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index 2c7f014..3b993cb 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -55,5 +55,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)+= >> bcm47xxnflash/ >> obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o >> obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o >> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ >> +obj-$(CONFIG_MTD_NAND_ARASAN)+= arasan_nand.o >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o >> diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c >> new file mode 100644 >> index 000..e882e63 >> --- /dev/null >> +++ b/drivers/mtd/nand/arasan_nand.c >> @@ -0,0 +1,1010 @@ >> +/* >> + * Arasan Nand Flash Controller Driver >> + * >> + * Copyright (C) 2014 - 2015 Xilinx, Inc. >> + * >> + * This program is free software; you can redistribute it and/or modify it >> under >> + * the terms of the GNU General Public License version 2 as published by the >> + * Free Software Foundation; either version 2 of the License, or (at your >> + * option) any later version. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define DRIVER_NAME "arasan_nand" >> +#define EVNT_TIMEOUT 1000 >> +#define STATUS_TIMEOUT 2000 >> + >> +#define PKT_OFST 0x00 >> +#define MEM_ADDR1_OFST 0x04 >> +#define MEM_ADDR2_OFST 0x08 >> +#define CMD_OFST 0x0C >> +#define PROG_OFST0x10 >> +#define INTR_STS_EN_OFST 0x14 >> +#define INTR_SIG_EN_OFST 0x18 >> +#define INTR_STS_OFST0x1C >> +#define READY_STS_OFST 0x20 >> +#define DMA_ADDR1_OFST 0x24 >> +#define FLASH_STS_OFST 0x28 >> +#define DATA_PORT_OFST 0x30 >> +#define ECC_OFST 0x34 >> +#define ECC_ERR_CNT_OFST 0x38 >> +#define ECC_SPR_CMD_OFST 0x3C >> +#define ECC_ERR_CNT_1BIT_OFST
Re: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
HI Brian, On Tue, Mar 8, 2016 at 5:37 AM, Brian Norris <computersforpe...@gmail.com> wrote: > + Boris > > Punnaiah, > > Can you fix the threading on your mail client? Your patch series does > not appear as a thread, because you didn't get the mail headers right > (References and In-Reply-To). If you're having trouble, try git-send-email. Sure and thanks for the review. I will address the below commnets in v6 and release the patches for review soon. Regards, Punnaiah. > > On Sat, Nov 21, 2015 at 08:09:48PM +0530, Punnaiah Choudary Kalluri wrote: >> Added the basic driver for Arasan Nand Flash Controller used in >> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit >> correction. >> >> Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> >> --- >> Changes in v5: >> - Renamed the driver filei as arasan_nand.c >> - Fixed all comments relaqted coding style >> - Fixed comments related to propagating the errors >> - Modified the anfc_write_page_hwecc as per the write_page >> prototype >> Changes in v4: >> - Added support for onfi timing mode configuration >> - Added clock suort >> - Added support for multiple chipselects >> Changes in v3: >> - Removed unused variables >> - Avoided busy loop and used jifies based implementation >> - Fixed compiler warnings "right shift count >= width of type" >> - Removed unneeded codei and improved error reporting >> - Added onfi version check to ensure reading the valid address cycles >> Changes in v2: >> - Added missing of.h to avoid kbuild system report error >> --- >> drivers/mtd/nand/Kconfig |6 + >> drivers/mtd/nand/Makefile |1 + >> drivers/mtd/nand/arasan_nand.c | 1010 >> >> 3 files changed, 1017 insertions(+) >> create mode 100644 drivers/mtd/nand/arasan_nand.c >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index 2896640..9c620fb 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -546,4 +546,10 @@ config MTD_NAND_HISI504 >> help >> Enables support for NAND controller on Hisilicon SoC Hip04. >> >> +config MTD_NAND_ARASAN > > I think you have some missing dependencies here, like HAS_IOMEM. > >> + tristate "Support for Arasan Nand Flash controller" >> + help >> + Enables the driver for the Arasan Nand Flash controller on >> + Zynq UltraScale+ MPSoC. >> + >> endif # MTD_NAND >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index 2c7f014..3b993cb 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -55,5 +55,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)+= >> bcm47xxnflash/ >> obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o >> obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o >> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ >> +obj-$(CONFIG_MTD_NAND_ARASAN)+= arasan_nand.o >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o >> diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c >> new file mode 100644 >> index 000..e882e63 >> --- /dev/null >> +++ b/drivers/mtd/nand/arasan_nand.c >> @@ -0,0 +1,1010 @@ >> +/* >> + * Arasan Nand Flash Controller Driver >> + * >> + * Copyright (C) 2014 - 2015 Xilinx, Inc. >> + * >> + * This program is free software; you can redistribute it and/or modify it >> under >> + * the terms of the GNU General Public License version 2 as published by the >> + * Free Software Foundation; either version 2 of the License, or (at your >> + * option) any later version. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define DRIVER_NAME "arasan_nand" >> +#define EVNT_TIMEOUT 1000 >> +#define STATUS_TIMEOUT 2000 >> + >> +#define PKT_OFST 0x00 >> +#define MEM_ADDR1_OFST 0x04 >> +#define MEM_ADDR2_OFST 0x08 >> +#define CMD_OFST 0x0C >> +#define PROG_OFST0x10 >> +#define INTR_STS_EN_OFST 0x14 >> +#define INTR_SIG_EN_OFST 0x18 >> +#define I
Re: [PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
HI Brian, On Tue, Mar 8, 2016 at 5:37 AM, Brian Norris wrote: > + Boris > > Punnaiah, > > Can you fix the threading on your mail client? Your patch series does > not appear as a thread, because you didn't get the mail headers right > (References and In-Reply-To). If you're having trouble, try git-send-email. Sure and thanks for the review. I will address the below commnets in v6 and release the patches for review soon. Regards, Punnaiah. > > On Sat, Nov 21, 2015 at 08:09:48PM +0530, Punnaiah Choudary Kalluri wrote: >> Added the basic driver for Arasan Nand Flash Controller used in >> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit >> correction. >> >> Signed-off-by: Punnaiah Choudary Kalluri >> --- >> Changes in v5: >> - Renamed the driver filei as arasan_nand.c >> - Fixed all comments relaqted coding style >> - Fixed comments related to propagating the errors >> - Modified the anfc_write_page_hwecc as per the write_page >> prototype >> Changes in v4: >> - Added support for onfi timing mode configuration >> - Added clock suort >> - Added support for multiple chipselects >> Changes in v3: >> - Removed unused variables >> - Avoided busy loop and used jifies based implementation >> - Fixed compiler warnings "right shift count >= width of type" >> - Removed unneeded codei and improved error reporting >> - Added onfi version check to ensure reading the valid address cycles >> Changes in v2: >> - Added missing of.h to avoid kbuild system report error >> --- >> drivers/mtd/nand/Kconfig |6 + >> drivers/mtd/nand/Makefile |1 + >> drivers/mtd/nand/arasan_nand.c | 1010 >> >> 3 files changed, 1017 insertions(+) >> create mode 100644 drivers/mtd/nand/arasan_nand.c >> >> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >> index 2896640..9c620fb 100644 >> --- a/drivers/mtd/nand/Kconfig >> +++ b/drivers/mtd/nand/Kconfig >> @@ -546,4 +546,10 @@ config MTD_NAND_HISI504 >> help >> Enables support for NAND controller on Hisilicon SoC Hip04. >> >> +config MTD_NAND_ARASAN > > I think you have some missing dependencies here, like HAS_IOMEM. > >> + tristate "Support for Arasan Nand Flash controller" >> + help >> + Enables the driver for the Arasan Nand Flash controller on >> + Zynq UltraScale+ MPSoC. >> + >> endif # MTD_NAND >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index 2c7f014..3b993cb 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -55,5 +55,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)+= >> bcm47xxnflash/ >> obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o >> obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o >> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ >> +obj-$(CONFIG_MTD_NAND_ARASAN)+= arasan_nand.o >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o >> diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c >> new file mode 100644 >> index 000..e882e63 >> --- /dev/null >> +++ b/drivers/mtd/nand/arasan_nand.c >> @@ -0,0 +1,1010 @@ >> +/* >> + * Arasan Nand Flash Controller Driver >> + * >> + * Copyright (C) 2014 - 2015 Xilinx, Inc. >> + * >> + * This program is free software; you can redistribute it and/or modify it >> under >> + * the terms of the GNU General Public License version 2 as published by the >> + * Free Software Foundation; either version 2 of the License, or (at your >> + * option) any later version. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define DRIVER_NAME "arasan_nand" >> +#define EVNT_TIMEOUT 1000 >> +#define STATUS_TIMEOUT 2000 >> + >> +#define PKT_OFST 0x00 >> +#define MEM_ADDR1_OFST 0x04 >> +#define MEM_ADDR2_OFST 0x08 >> +#define CMD_OFST 0x0C >> +#define PROG_OFST0x10 >> +#define INTR_STS_EN_OFST 0x14 >> +#define INTR_SIG_EN_OFST 0x18 >> +#define INTR_STS_OFST0x1C >> +#define REA
Re: [PATCH] mtd: Expand the ecc placement locations to 1216
Hi Boris, On Tue, Dec 1, 2015 at 4:45 PM, Boris Brezillon wrote: > Brian, Punnaiah, > > On Fri, 20 Nov 2015 11:33:42 -0800 > Brian Norris wrote: > >> On Thu, Nov 05, 2015 at 10:28:55PM +0530, Punnaiah Choudary Kalluri wrote: >> > Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes. >> > So, increasing the maximum ecc placement locations to 1216 >> >> I'd really prefer not increasing the size of the internal arrays any >> more. The structures should be rewritten to be dynamic. > > I already started this migration (you can find the code here [1]). I > was planning to rework this series to make the eccpos definition mimic > what's done for oobfree (as suggested by Brian) before sending it, but > I'm not sure when I'll be able to do that, so if you really need that > quickly I suggest you submit those patches instead of reimplementing > it yourself. > Sure. let me check your implementation and then send these patches for review with your sign off. Thanks, Punnaiah > Best Regards, > > Boris > > [1]https://github.com/bbrezillon/linux-sunxi/commits/nand/ecclayout > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- 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/
Re: [PATCH] mtd: Expand the ecc placement locations to 1216
Hi Brian,
On Tue, Dec 1, 2015 at 2:41 AM, Brian Norris
wrote:
> Hi Punnaiah,
>
> On Sat, Nov 21, 2015 at 08:59:15PM +0530, punnaiah choudary kalluri wrote:
>> On Sat, Nov 21, 2015 at 1:03 AM, Brian Norris
>> wrote:
>> > On Thu, Nov 05, 2015 at 10:28:55PM +0530, Punnaiah Choudary Kalluri wrote:
>> >> Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes.
>> >> So, increasing the maximum ecc placement locations to 1216
>> >
>> > I'd really prefer not increasing the size of the internal arrays any
>> > more. The structures should be rewritten to be dynamic.
>>
>> Ok. I have seen the comment "nand_ecclayout should be expandable in the
>> future simply by the above macros" and so increased the macro sizes.
>> As you said, it is ideal to have memory allocated dynamically for eccpos and
>> oobfree fields.
>
> Yes, it *can* be done. Previously, we couldn't do this, because any
> change there would also change the ABI, which is off limits, but I fixed
> that by separating the 'nand_ecclayout' and 'nand_ecclayout_user'
> structs. That still doesn't make it preferable. These structs are
> getting pretty big, and they hold a very low density of information...
>
>> >
>> >> Signed-off-by: Punnaiah Choudary Kalluri
>> >> ---
>> >> include/linux/mtd/mtd.h| 2 +-
>> >> include/uapi/mtd/mtd-abi.h | 4 ++--
>> >> 2 files changed, 3 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
>> >> index f17fa75..1fd3cc6 100644
>> >> --- a/include/linux/mtd/mtd.h
>> >> +++ b/include/linux/mtd/mtd.h
>> >> @@ -95,7 +95,7 @@ struct mtd_oob_ops {
>> >> };
>> >>
>> >> #define MTD_MAX_OOBFREE_ENTRIES_LARGE32
>> >> -#define MTD_MAX_ECCPOS_ENTRIES_LARGE 640
>> >> +#define MTD_MAX_ECCPOS_ENTRIES_LARGE 1216
>> >> /*
>> >> * Internal ECC layout control structure. For historical reasons, there
>> >> is a
>> >> * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is
>> >> retained
>> >> diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
>> >> index 763bb69..c4d592c 100644
>> >> --- a/include/uapi/mtd/mtd-abi.h
>> >> +++ b/include/uapi/mtd/mtd-abi.h
>> >> @@ -220,8 +220,8 @@ struct nand_oobfree {
>> >> __u32 length;
>> >> };
>> >>
>> >> -#define MTD_MAX_OOBFREE_ENTRIES 8
>> >> -#define MTD_MAX_ECCPOS_ENTRIES 64
>> >> +#define MTD_MAX_OOBFREE_ENTRIES 32
>> >> +#define MTD_MAX_ECCPOS_ENTRIES 1216
>> >
>> > NAK. This is part of the ABI, and changing this will break user space.
>> > If you actually bothered to read code, you might understand why there
>> > are now internal and external versions of this struct. The external
>> > (user space) version cannot be changed. The internal version can be
>> > refactored, as long as the external version still maintains some sanity,
>> > at least for old/small devices.
>>
>> Sorry, I am confused here.
>> Arasan nand controller supports 24 bit ecc and uses BCH algorithm. So,
>> it requires
>> 672 ecc positions. in this case, how the user space know which are the free
>> slots available in spare area?
>> because as per the above definitions only 64 positions can be defined.
>
> If you actually need to know this info from user space, then you need to
> define a new interface to expose that. The existing one is legacy, and
> it is insufficient for most modern use cases. It won't work for you.
>
> Other mechanisms can already help you though. For one, auto-placed OOB
> (e.g., 'nandwrite --autoplace') can let the MTD layer automatically put
> your data into the available spare area.
>
> Why do you need to access the spare area anyway? Modern NAND filesystems
> shouldn't really be storing anything there anyway.
>
I have tested jffs2 and ubifs file system using arasan nand driver but
observed issues
with jffs2 filesystem. While debugging further found that the jffs2
file system is using
the oob area for storing the clear markers.
Not only for file system, probably one can implement application for
accessing the
nand in raw mode and may utilize the oob area for other purposes like
storing the
encryption/decryption key associated with the page data.
not related to this patch, request your time and help for reviewing
the arasan nand driver patch.
http://permalink.gmane.org/gmane.linux.kernel/2090815
Regards,
Punnaiah
> Brian
> --
> 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 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/
Re: [PATCH] mtd: Expand the ecc placement locations to 1216
Hi Brian,
On Tue, Dec 1, 2015 at 2:41 AM, Brian Norris
<computersforpe...@gmail.com> wrote:
> Hi Punnaiah,
>
> On Sat, Nov 21, 2015 at 08:59:15PM +0530, punnaiah choudary kalluri wrote:
>> On Sat, Nov 21, 2015 at 1:03 AM, Brian Norris
>> <computersforpe...@gmail.com> wrote:
>> > On Thu, Nov 05, 2015 at 10:28:55PM +0530, Punnaiah Choudary Kalluri wrote:
>> >> Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes.
>> >> So, increasing the maximum ecc placement locations to 1216
>> >
>> > I'd really prefer not increasing the size of the internal arrays any
>> > more. The structures should be rewritten to be dynamic.
>>
>> Ok. I have seen the comment "nand_ecclayout should be expandable in the
>> future simply by the above macros" and so increased the macro sizes.
>> As you said, it is ideal to have memory allocated dynamically for eccpos and
>> oobfree fields.
>
> Yes, it *can* be done. Previously, we couldn't do this, because any
> change there would also change the ABI, which is off limits, but I fixed
> that by separating the 'nand_ecclayout' and 'nand_ecclayout_user'
> structs. That still doesn't make it preferable. These structs are
> getting pretty big, and they hold a very low density of information...
>
>> >
>> >> Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
>> >> ---
>> >> include/linux/mtd/mtd.h| 2 +-
>> >> include/uapi/mtd/mtd-abi.h | 4 ++--
>> >> 2 files changed, 3 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
>> >> index f17fa75..1fd3cc6 100644
>> >> --- a/include/linux/mtd/mtd.h
>> >> +++ b/include/linux/mtd/mtd.h
>> >> @@ -95,7 +95,7 @@ struct mtd_oob_ops {
>> >> };
>> >>
>> >> #define MTD_MAX_OOBFREE_ENTRIES_LARGE32
>> >> -#define MTD_MAX_ECCPOS_ENTRIES_LARGE 640
>> >> +#define MTD_MAX_ECCPOS_ENTRIES_LARGE 1216
>> >> /*
>> >> * Internal ECC layout control structure. For historical reasons, there
>> >> is a
>> >> * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is
>> >> retained
>> >> diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
>> >> index 763bb69..c4d592c 100644
>> >> --- a/include/uapi/mtd/mtd-abi.h
>> >> +++ b/include/uapi/mtd/mtd-abi.h
>> >> @@ -220,8 +220,8 @@ struct nand_oobfree {
>> >> __u32 length;
>> >> };
>> >>
>> >> -#define MTD_MAX_OOBFREE_ENTRIES 8
>> >> -#define MTD_MAX_ECCPOS_ENTRIES 64
>> >> +#define MTD_MAX_OOBFREE_ENTRIES 32
>> >> +#define MTD_MAX_ECCPOS_ENTRIES 1216
>> >
>> > NAK. This is part of the ABI, and changing this will break user space.
>> > If you actually bothered to read code, you might understand why there
>> > are now internal and external versions of this struct. The external
>> > (user space) version cannot be changed. The internal version can be
>> > refactored, as long as the external version still maintains some sanity,
>> > at least for old/small devices.
>>
>> Sorry, I am confused here.
>> Arasan nand controller supports 24 bit ecc and uses BCH algorithm. So,
>> it requires
>> 672 ecc positions. in this case, how the user space know which are the free
>> slots available in spare area?
>> because as per the above definitions only 64 positions can be defined.
>
> If you actually need to know this info from user space, then you need to
> define a new interface to expose that. The existing one is legacy, and
> it is insufficient for most modern use cases. It won't work for you.
>
> Other mechanisms can already help you though. For one, auto-placed OOB
> (e.g., 'nandwrite --autoplace') can let the MTD layer automatically put
> your data into the available spare area.
>
> Why do you need to access the spare area anyway? Modern NAND filesystems
> shouldn't really be storing anything there anyway.
>
I have tested jffs2 and ubifs file system using arasan nand driver but
observed issues
with jffs2 filesystem. While debugging further found that the jffs2
file system is using
the oob area for storing the clear markers.
Not only for file system, probably one can implement application for
accessing the
nand in raw mode and may utilize the oob area for other purposes like
storing the
encryption/decryption key associated with the page data.
not related to this patch, request your time and help for reviewing
the arasan nand driver patch.
http://permalink.gmane.org/gmane.linux.kernel/2090815
Regards,
Punnaiah
> Brian
> --
> 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 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/
Re: [PATCH] mtd: Expand the ecc placement locations to 1216
Hi Boris, On Tue, Dec 1, 2015 at 4:45 PM, Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > Brian, Punnaiah, > > On Fri, 20 Nov 2015 11:33:42 -0800 > Brian Norris <computersforpe...@gmail.com> wrote: > >> On Thu, Nov 05, 2015 at 10:28:55PM +0530, Punnaiah Choudary Kalluri wrote: >> > Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes. >> > So, increasing the maximum ecc placement locations to 1216 >> >> I'd really prefer not increasing the size of the internal arrays any >> more. The structures should be rewritten to be dynamic. > > I already started this migration (you can find the code here [1]). I > was planning to rework this series to make the eccpos definition mimic > what's done for oobfree (as suggested by Brian) before sending it, but > I'm not sure when I'll be able to do that, so if you really need that > quickly I suggest you submit those patches instead of reimplementing > it yourself. > Sure. let me check your implementation and then send these patches for review with your sign off. Thanks, Punnaiah > Best Regards, > > Boris > > [1]https://github.com/bbrezillon/linux-sunxi/commits/nand/ecclayout > > -- > Boris Brezillon, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com -- 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/
Re: [PATCH] mtd: Expand the ecc placement locations to 1216
On Sat, Nov 21, 2015 at 1:03 AM, Brian Norris
wrote:
> On Thu, Nov 05, 2015 at 10:28:55PM +0530, Punnaiah Choudary Kalluri wrote:
>> Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes.
>> So, increasing the maximum ecc placement locations to 1216
>
> I'd really prefer not increasing the size of the internal arrays any
> more. The structures should be rewritten to be dynamic.
Ok. I have seen the comment "nand_ecclayout should be expandable in the
future simply by the above macros" and so increased the macro sizes.
As you said, it is ideal to have memory allocated dynamically for eccpos and
oobfree fields.
>
>> Signed-off-by: Punnaiah Choudary Kalluri
>> ---
>> include/linux/mtd/mtd.h| 2 +-
>> include/uapi/mtd/mtd-abi.h | 4 ++--
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
>> index f17fa75..1fd3cc6 100644
>> --- a/include/linux/mtd/mtd.h
>> +++ b/include/linux/mtd/mtd.h
>> @@ -95,7 +95,7 @@ struct mtd_oob_ops {
>> };
>>
>> #define MTD_MAX_OOBFREE_ENTRIES_LARGE32
>> -#define MTD_MAX_ECCPOS_ENTRIES_LARGE 640
>> +#define MTD_MAX_ECCPOS_ENTRIES_LARGE 1216
>> /*
>> * Internal ECC layout control structure. For historical reasons, there is a
>> * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is
>> retained
>> diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
>> index 763bb69..c4d592c 100644
>> --- a/include/uapi/mtd/mtd-abi.h
>> +++ b/include/uapi/mtd/mtd-abi.h
>> @@ -220,8 +220,8 @@ struct nand_oobfree {
>> __u32 length;
>> };
>>
>> -#define MTD_MAX_OOBFREE_ENTRIES 8
>> -#define MTD_MAX_ECCPOS_ENTRIES 64
>> +#define MTD_MAX_OOBFREE_ENTRIES 32
>> +#define MTD_MAX_ECCPOS_ENTRIES 1216
>
> NAK. This is part of the ABI, and changing this will break user space.
> If you actually bothered to read code, you might understand why there
> are now internal and external versions of this struct. The external
> (user space) version cannot be changed. The internal version can be
> refactored, as long as the external version still maintains some sanity,
> at least for old/small devices.
Sorry, I am confused here.
Arasan nand controller supports 24 bit ecc and uses BCH algorithm. So,
it requires
672 ecc positions. in this case, how the user space know which are the free
slots available in spare area?
because as per the above definitions only 64 positions can be defined.
Regards,
Punnaiah
>
>> /*
>> * OBSOLETE: ECC layout control structure. Exported to user-space via ioctl
>> * ECCGETLAYOUT for backwards compatbility and should not be mistaken as a
>
> Brian
--
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/
[PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Added the basic driver for Arasan Nand Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v5: - Renamed the driver filei as arasan_nand.c - Fixed all comments relaqted coding style - Fixed comments related to propagating the errors - Modified the anfc_write_page_hwecc as per the write_page prototype Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report error --- drivers/mtd/nand/Kconfig |6 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/arasan_nand.c | 1010 3 files changed, 1017 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 2896640..9c620fb 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -546,4 +546,10 @@ config MTD_NAND_HISI504 help Enables support for NAND controller on Hisilicon SoC Hip04. +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + help + Enables the driver for the Arasan Nand Flash controller on + Zynq UltraScale+ MPSoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 2c7f014..3b993cb 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -55,5 +55,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c new file mode 100644 index 000..e882e63 --- /dev/null +++ b/drivers/mtd/nand/arasan_nand.c @@ -0,0 +1,1010 @@ +/* + * Arasan Nand Flash Controller Driver + * + * Copyright (C) 2014 - 2015 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nand" +#define EVNT_TIMEOUT 1000 +#define STATUS_TIMEOUT 2000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_REG 0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENABLE BIT(31) +#define DMA_EN_MASKGENMASK(27, 26) +#define DMA_ENABLE 0x2 +#define DMA_EN_SHIFT 26 +#define REG_PAGE_SIZE_MASK GENMASK(25, 23) +#define REG_PAGE_SIZE_SHIFT23 +#define REG_PAGE_SIZE_512 0 +#define REG_PAGE_SIZE_1K 5 +#define REG_PAGE_SIZE_2K 1 +#define REG_PAGE_SIZE_4K 2 +#define REG_PAGE_SIZE_8K 3 +#define REG_PAGE_SIZE_16K 4 +#define CMD2_SHIFT 8 +#define ADDR_CYCLES_SHIFT 28 + +#define XFER_COMPLETE BIT(2) +#define READ_READY BIT(1) +#define WRITE_READYBIT(0) +#define MBIT_ERROR BIT(3) +#define ERR_INTRPT BIT(4) + +#define PROG_PGRD BIT(0) +#define PROG_ERASE BIT(2) +#define PROG_STATUSBIT(3) +#define PROG_PGPROG
[PATCH v5 1/3] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri
---
Changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..02e1ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,34 @@
+Arasan Nand Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables Dma support
+- num-cs: Number of chip selects used
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ num-cs = <1>;
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
--
2.1.2
--
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/
[PATCH v5 3/3] mtd: nand: Add macro definition for nvddr interface mode
Added macro definition for nvddr data interface mode field in the sub feature parameter of onfi timing mode configuration. Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v5: - None Changes in v4: - New change --- include/linux/mtd/nand.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 5a9d1d4..1a8614f 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -215,6 +215,9 @@ struct nand_chip; #define ONFI_TIMING_MODE_5 (1 << 5) #define ONFI_TIMING_MODE_UNKNOWN (1 << 6) +/* ONFI data interface mode */ +#define ONFI_DATA_INTERFACE_NVDDR (1 << 4) + /* ONFI feature address */ #define ONFI_FEATURE_ADDR_TIMING_MODE 0x1 -- 2.1.2 -- 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/
Re: [PATCH] mtd: Expand the ecc placement locations to 1216
On Sat, Nov 21, 2015 at 1:03 AM, Brian Norris
<computersforpe...@gmail.com> wrote:
> On Thu, Nov 05, 2015 at 10:28:55PM +0530, Punnaiah Choudary Kalluri wrote:
>> Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes.
>> So, increasing the maximum ecc placement locations to 1216
>
> I'd really prefer not increasing the size of the internal arrays any
> more. The structures should be rewritten to be dynamic.
Ok. I have seen the comment "nand_ecclayout should be expandable in the
future simply by the above macros" and so increased the macro sizes.
As you said, it is ideal to have memory allocated dynamically for eccpos and
oobfree fields.
>
>> Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
>> ---
>> include/linux/mtd/mtd.h| 2 +-
>> include/uapi/mtd/mtd-abi.h | 4 ++--
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
>> index f17fa75..1fd3cc6 100644
>> --- a/include/linux/mtd/mtd.h
>> +++ b/include/linux/mtd/mtd.h
>> @@ -95,7 +95,7 @@ struct mtd_oob_ops {
>> };
>>
>> #define MTD_MAX_OOBFREE_ENTRIES_LARGE32
>> -#define MTD_MAX_ECCPOS_ENTRIES_LARGE 640
>> +#define MTD_MAX_ECCPOS_ENTRIES_LARGE 1216
>> /*
>> * Internal ECC layout control structure. For historical reasons, there is a
>> * similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is
>> retained
>> diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
>> index 763bb69..c4d592c 100644
>> --- a/include/uapi/mtd/mtd-abi.h
>> +++ b/include/uapi/mtd/mtd-abi.h
>> @@ -220,8 +220,8 @@ struct nand_oobfree {
>> __u32 length;
>> };
>>
>> -#define MTD_MAX_OOBFREE_ENTRIES 8
>> -#define MTD_MAX_ECCPOS_ENTRIES 64
>> +#define MTD_MAX_OOBFREE_ENTRIES 32
>> +#define MTD_MAX_ECCPOS_ENTRIES 1216
>
> NAK. This is part of the ABI, and changing this will break user space.
> If you actually bothered to read code, you might understand why there
> are now internal and external versions of this struct. The external
> (user space) version cannot be changed. The internal version can be
> refactored, as long as the external version still maintains some sanity,
> at least for old/small devices.
Sorry, I am confused here.
Arasan nand controller supports 24 bit ecc and uses BCH algorithm. So,
it requires
672 ecc positions. in this case, how the user space know which are the free
slots available in spare area?
because as per the above definitions only 64 positions can be defined.
Regards,
Punnaiah
>
>> /*
>> * OBSOLETE: ECC layout control structure. Exported to user-space via ioctl
>> * ECCGETLAYOUT for backwards compatbility and should not be mistaken as a
>
> Brian
--
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/
[PATCH v5 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Added the basic driver for Arasan Nand Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> --- Changes in v5: - Renamed the driver filei as arasan_nand.c - Fixed all comments relaqted coding style - Fixed comments related to propagating the errors - Modified the anfc_write_page_hwecc as per the write_page prototype Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report error --- drivers/mtd/nand/Kconfig |6 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/arasan_nand.c | 1010 3 files changed, 1017 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nand.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 2896640..9c620fb 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -546,4 +546,10 @@ config MTD_NAND_HISI504 help Enables support for NAND controller on Hisilicon SoC Hip04. +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + help + Enables the driver for the Arasan Nand Flash controller on + Zynq UltraScale+ MPSoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 2c7f014..3b993cb 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -55,5 +55,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nand.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/arasan_nand.c b/drivers/mtd/nand/arasan_nand.c new file mode 100644 index 000..e882e63 --- /dev/null +++ b/drivers/mtd/nand/arasan_nand.c @@ -0,0 +1,1010 @@ +/* + * Arasan Nand Flash Controller Driver + * + * Copyright (C) 2014 - 2015 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nand" +#define EVNT_TIMEOUT 1000 +#define STATUS_TIMEOUT 2000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_REG 0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENABLE BIT(31) +#define DMA_EN_MASKGENMASK(27, 26) +#define DMA_ENABLE 0x2 +#define DMA_EN_SHIFT 26 +#define REG_PAGE_SIZE_MASK GENMASK(25, 23) +#define REG_PAGE_SIZE_SHIFT23 +#define REG_PAGE_SIZE_512 0 +#define REG_PAGE_SIZE_1K 5 +#define REG_PAGE_SIZE_2K 1 +#define REG_PAGE_SIZE_4K 2 +#define REG_PAGE_SIZE_8K 3 +#define REG_PAGE_SIZE_16K 4 +#define CMD2_SHIFT 8 +#define ADDR_CYCLES_SHIFT 28 + +#define XFER_COMPLETE BIT(2) +#define READ_READY BIT(1) +#define WRITE_READYBIT(0) +#define MBIT_ERROR BIT(3) +#define ERR_INTRPT BIT(4) + +#define PROG_PGRD BIT(0) +#define PROG_ERASE BIT(2) +#define PROG_STATUSBIT(3) +#defi
[PATCH v5 1/3] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
---
Changes in v5:
- None
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..02e1ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,34 @@
+Arasan Nand Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables Dma support
+- num-cs: Number of chip selects used
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ num-cs = <1>;
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
--
2.1.2
--
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/
[PATCH v5 3/3] mtd: nand: Add macro definition for nvddr interface mode
Added macro definition for nvddr data interface mode field in the sub feature parameter of onfi timing mode configuration. Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> --- Changes in v5: - None Changes in v4: - New change --- include/linux/mtd/nand.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 5a9d1d4..1a8614f 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -215,6 +215,9 @@ struct nand_chip; #define ONFI_TIMING_MODE_5 (1 << 5) #define ONFI_TIMING_MODE_UNKNOWN (1 << 6) +/* ONFI data interface mode */ +#define ONFI_DATA_INTERFACE_NVDDR (1 << 4) + /* ONFI feature address */ #define ONFI_FEATURE_ADDR_TIMING_MODE 0x1 -- 2.1.2 -- 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/
[PATCH] net: macb: Add support for sgmii phy interface
This patch adds support for the sgmii phy interface. Signed-off-by: Punnaiah Choudary Kalluri --- drivers/net/ethernet/cadence/macb.c | 4 drivers/net/ethernet/cadence/macb.h | 5 + 2 files changed, 9 insertions(+) diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 88c1e1a..169059c 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -1682,6 +1682,8 @@ static void macb_init_hw(struct macb *bp) macb_set_hwaddr(bp); config = macb_mdc_clk_div(bp); + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) + config |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL); config |= MACB_BF(RBOF, NET_IP_ALIGN); /* Make eth data aligned */ config |= MACB_BIT(PAE);/* PAuse Enable */ config |= MACB_BIT(DRFCS); /* Discard Rx FCS */ @@ -2416,6 +2418,8 @@ static int macb_init(struct platform_device *pdev) /* Set MII management clock divider */ val = macb_mdc_clk_div(bp); val |= macb_dbw(bp); + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) + val |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL); macb_writel(bp, NCFGR, val); return 0; diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h index 6e1faea..d83b0db 100644 --- a/drivers/net/ethernet/cadence/macb.h +++ b/drivers/net/ethernet/cadence/macb.h @@ -215,12 +215,17 @@ /* GEM specific NCFGR bitfields. */ #define GEM_GBE_OFFSET 10 /* Gigabit mode enable */ #define GEM_GBE_SIZE 1 +#define GEM_PCSSEL_OFFSET 11 +#define GEM_PCSSEL_SIZE1 #define GEM_CLK_OFFSET 18 /* MDC clock division */ #define GEM_CLK_SIZE 3 #define GEM_DBW_OFFSET 21 /* Data bus width */ #define GEM_DBW_SIZE 2 #define GEM_RXCOEN_OFFSET 24 #define GEM_RXCOEN_SIZE1 +#define GEM_SGMIIEN_OFFSET 27 +#define GEM_SGMIIEN_SIZE 1 + /* Constants for data bus width. */ #define GEM_DBW32 0 /* 32 bit AMBA AHB data bus width */ -- 2.1.2 -- 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/
[PATCH] net: macb: Add support for sgmii phy interface
This patch adds support for the sgmii phy interface. Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> --- drivers/net/ethernet/cadence/macb.c | 4 drivers/net/ethernet/cadence/macb.h | 5 + 2 files changed, 9 insertions(+) diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 88c1e1a..169059c 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -1682,6 +1682,8 @@ static void macb_init_hw(struct macb *bp) macb_set_hwaddr(bp); config = macb_mdc_clk_div(bp); + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) + config |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL); config |= MACB_BF(RBOF, NET_IP_ALIGN); /* Make eth data aligned */ config |= MACB_BIT(PAE);/* PAuse Enable */ config |= MACB_BIT(DRFCS); /* Discard Rx FCS */ @@ -2416,6 +2418,8 @@ static int macb_init(struct platform_device *pdev) /* Set MII management clock divider */ val = macb_mdc_clk_div(bp); val |= macb_dbw(bp); + if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) + val |= GEM_BIT(SGMIIEN) | GEM_BIT(PCSSEL); macb_writel(bp, NCFGR, val); return 0; diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h index 6e1faea..d83b0db 100644 --- a/drivers/net/ethernet/cadence/macb.h +++ b/drivers/net/ethernet/cadence/macb.h @@ -215,12 +215,17 @@ /* GEM specific NCFGR bitfields. */ #define GEM_GBE_OFFSET 10 /* Gigabit mode enable */ #define GEM_GBE_SIZE 1 +#define GEM_PCSSEL_OFFSET 11 +#define GEM_PCSSEL_SIZE1 #define GEM_CLK_OFFSET 18 /* MDC clock division */ #define GEM_CLK_SIZE 3 #define GEM_DBW_OFFSET 21 /* Data bus width */ #define GEM_DBW_SIZE 2 #define GEM_RXCOEN_OFFSET 24 #define GEM_RXCOEN_SIZE1 +#define GEM_SGMIIEN_OFFSET 27 +#define GEM_SGMIIEN_SIZE 1 + /* Constants for data bus width. */ #define GEM_DBW32 0 /* 32 bit AMBA AHB data bus width */ -- 2.1.2 -- 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/
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Thu, Nov 12, 2015 at 4:02 PM, Andy Shevchenko
wrote:
> On Thu, 2015-11-12 at 10:18 +0530, punnaiah choudary kalluri wrote:
>> On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko
>> wrote:
>> > On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote:
>> > > Added the basic driver for Arasan Nand Flash Controller used in
>> > > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
>> > > correction.
>> > >
>> >
>> > > +config MTD_NAND_ARASAN
>> > > + tristate "Support for Arasan Nand Flash controller"
>> > > + depends on MTD_NAND
>> >
>> > This looks useless since you can't see the item without MTD_NAND is
>> > chosen.
>> >
>> > > + help
>> > > + Enables the driver for the Arasan Nand Flash controller
>> > > on
>> > > + Zynq UltraScale+ MPSoC.
>> > > +
>> > > endif # MTD_NAND
>> > >
>> >
>> > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o
>> >
>> > "nfc" part a bit ambiguous since NFC might be Near Field
>> > Communication.
>>
>> This driver is under mtd/nand so, there is no point of confusion and
>> in this context nfc is nand flash controller.
>
> Imagine that at some point arasan (whatever) releases NFC chip, and
> someone puts the driver under corresponding folder but with the same
> file name (and driver name). Do you see a problem? I see two:
> - if you built-in both how you supply command line parameters?
> - some platform code may do request_module() or
> platform_driver_register() with the name you provided as DRIVER_NAME.
>
> So, I just suggest distinguishable name. But it's a call of NAND
> subsystem maintainer.
>
Ok. Thanks. I will rename this file.
>> >
>> > Perhaps "nand_fc" or something like that?
>> >
>
>> > > +#include
>> > > +
>> > > +#define DRIVER_NAME "arasan_nfc"
>> >
>> > Ditto.
>> >
>> > > +static int anfc_device_ready(struct mtd_info *mtd,
>> > > + struct nand_chip *chip)
>> > > +{
>> > > + u8 status;
>> > > + unsigned long timeout = jiffies + STATUS_TIMEOUT;
>> > > +
>> > > + do {
>> > > + chip->cmdfunc(mtd, NAND_CMD_STATUS, 0, 0);
>> > > + status = chip->read_byte(mtd);
>> > > + if (status & ONFI_STATUS_READY) {
>> >
>> > > + if (status & ONFI_STATUS_FAIL)
>> > > + return NAND_STATUS_FAIL;
>> >
>> > This is invariant to the loop, perhaps move outside.
>>
>> Nand device is ready means it is ready to accept next command and
>> it is done with previous command. It doesn't mean that previous
>> command is success, it can fail also.
>
> This is style and logic comment. I do not object how NAND works.
>
>> >
>> > > + break;
>> > > + }
>> > > + cpu_relax();
>> > > + } while (!time_after_eq(jiffies, timeout));
>
> Just move it here. It will be the same, but unload busy loop.
>
It can be done. I will modify accordingly
Thanks,
Punnaiah
> Did I miss something?
>
>> > > +
>> > > + if (time_after_eq(jiffies, timeout)) {
>> > > + pr_err("%s timed out\n", __func__);
>> >
>> > dev_err?
>> >
>
>> > > +static void anfc_read_buf(struct mtd_info *mtd, uint8_t *buf,
>> > > int
>> > > len)
>> > > +{
>> > > + u32 i, pktcount, buf_rd_cnt = 0, pktsize;
>> >
>> > Type for i looks unsigned int, why u32? Same question for all
>> > variables
>> > that are not used to directly program HW.
>> >
>
> u32 and other derivatives mostly common when you program HW. Here for
> simple stuff better to use plain types, therefore unsigned int.
>
>> > > int len)
>> > > +{
>> > > + u32 buf_wr_cnt = 0, pktcount = 1, i, pktsize;
>> >
>> > Useless assignment of pktcount. Check all your definition blocks
>> > for
>> > similar thing.
>>
>> what is the problem with u32 here ? may be i am missing something
>> here but
>> i really want to know the reason.
>
> Ditto.
>
>> > > + writel(lower_32_bits(paddr), nfc->base +
>> > > DMA_ADDR0_OFST);
>> > > + writel(upper_32_bits(paddr), nfc->base +
>> > > DMA_ADDR1_OFST);
>> >
>> > lo_hi_writeq();
>>
>> Ok. let me check if this function is available across all
>> the platforms.
>
> The same spread as for writel().
> If your HW allows you to do 64-bit writes on 64-bit platforms, just
> use writeq(), but still include io-64-nonatomic-lo-hi.h (or how it's
> called nowadays).
>
> --
> Andy Shevchenko
> Intel Finland Oy
>
> --
> 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 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/
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Thu, Nov 12, 2015 at 4:02 PM, Andy Shevchenko
<andriy.shevche...@linux.intel.com> wrote:
> On Thu, 2015-11-12 at 10:18 +0530, punnaiah choudary kalluri wrote:
>> On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko
>> <andriy.shevche...@linux.intel.com> wrote:
>> > On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote:
>> > > Added the basic driver for Arasan Nand Flash Controller used in
>> > > Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
>> > > correction.
>> > >
>> >
>> > > +config MTD_NAND_ARASAN
>> > > + tristate "Support for Arasan Nand Flash controller"
>> > > + depends on MTD_NAND
>> >
>> > This looks useless since you can't see the item without MTD_NAND is
>> > chosen.
>> >
>> > > + help
>> > > + Enables the driver for the Arasan Nand Flash controller
>> > > on
>> > > + Zynq UltraScale+ MPSoC.
>> > > +
>> > > endif # MTD_NAND
>> > >
>> >
>> > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o
>> >
>> > "nfc" part a bit ambiguous since NFC might be Near Field
>> > Communication.
>>
>> This driver is under mtd/nand so, there is no point of confusion and
>> in this context nfc is nand flash controller.
>
> Imagine that at some point arasan (whatever) releases NFC chip, and
> someone puts the driver under corresponding folder but with the same
> file name (and driver name). Do you see a problem? I see two:
> - if you built-in both how you supply command line parameters?
> - some platform code may do request_module() or
> platform_driver_register() with the name you provided as DRIVER_NAME.
>
> So, I just suggest distinguishable name. But it's a call of NAND
> subsystem maintainer.
>
Ok. Thanks. I will rename this file.
>> >
>> > Perhaps "nand_fc" or something like that?
>> >
>
>> > > +#include
>> > > +
>> > > +#define DRIVER_NAME "arasan_nfc"
>> >
>> > Ditto.
>> >
>> > > +static int anfc_device_ready(struct mtd_info *mtd,
>> > > + struct nand_chip *chip)
>> > > +{
>> > > + u8 status;
>> > > + unsigned long timeout = jiffies + STATUS_TIMEOUT;
>> > > +
>> > > + do {
>> > > + chip->cmdfunc(mtd, NAND_CMD_STATUS, 0, 0);
>> > > + status = chip->read_byte(mtd);
>> > > + if (status & ONFI_STATUS_READY) {
>> >
>> > > + if (status & ONFI_STATUS_FAIL)
>> > > + return NAND_STATUS_FAIL;
>> >
>> > This is invariant to the loop, perhaps move outside.
>>
>> Nand device is ready means it is ready to accept next command and
>> it is done with previous command. It doesn't mean that previous
>> command is success, it can fail also.
>
> This is style and logic comment. I do not object how NAND works.
>
>> >
>> > > + break;
>> > > + }
>> > > + cpu_relax();
>> > > + } while (!time_after_eq(jiffies, timeout));
>
> Just move it here. It will be the same, but unload busy loop.
>
It can be done. I will modify accordingly
Thanks,
Punnaiah
> Did I miss something?
>
>> > > +
>> > > + if (time_after_eq(jiffies, timeout)) {
>> > > + pr_err("%s timed out\n", __func__);
>> >
>> > dev_err?
>> >
>
>> > > +static void anfc_read_buf(struct mtd_info *mtd, uint8_t *buf,
>> > > int
>> > > len)
>> > > +{
>> > > + u32 i, pktcount, buf_rd_cnt = 0, pktsize;
>> >
>> > Type for i looks unsigned int, why u32? Same question for all
>> > variables
>> > that are not used to directly program HW.
>> >
>
> u32 and other derivatives mostly common when you program HW. Here for
> simple stuff better to use plain types, therefore unsigned int.
>
>> > > int len)
>> > > +{
>> > > + u32 buf_wr_cnt = 0, pktcount = 1, i, pktsize;
>> >
>> > Useless assignment of pktcount. Check all your definition blocks
>> > for
>> > similar thing.
>>
>> what is the problem with u32 here ? may be i am missing something
>> here but
>> i really want to know the rea
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko
wrote:
> On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote:
>> Added the basic driver for Arasan Nand Flash Controller used in
>> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
>> correction.
>>
>
>> +config MTD_NAND_ARASAN
>> + tristate "Support for Arasan Nand Flash controller"
>> + depends on MTD_NAND
>
> This looks useless since you can't see the item without MTD_NAND is
> chosen.
>
>> + help
>> + Enables the driver for the Arasan Nand Flash controller on
>> + Zynq UltraScale+ MPSoC.
>> +
>> endif # MTD_NAND
>>
>
> +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o
>
> "nfc" part a bit ambiguous since NFC might be Near Field Communication.
>
> Perhaps "nand_fc" or something like that?
>
This driver is under mtd/nand so, there is no point of confusion here and
in this context nfc is nand flash controller.
>> +static u8 anfc_page(u32 pagesize)
>> +{
>> + switch (pagesize) {
>> + case 512:
>> + return PAGE_SIZE_512;
>> + case 2048:
>> + return PAGE_SIZE_2K;
>> + case 4096:
>> + return PAGE_SIZE_4K;
>> + case 8192:
>> + return PAGE_SIZE_8K;
>> + case 16384:
>> + return PAGE_SIZE_16K;
>> + case 1024:
>
> Why not keep sorted here?
>
It is sorted based on the return value. I will change the
sorting order based on the page size bytes.
>> + return PAGE_SIZE_1K;
>> + default:
>> + break;
>> + }
>> +
>> + return 0;
>
>
>
>> +}
>> +
>> +static inline void anfc_enable_intrs(struct anfc *nfc, u32 val)
>> +{
>> + writel(val, nfc->base + INTR_STS_EN_OFST);
>> + writel(val, nfc->base + INTR_SIG_EN_OFST);
>> +}
>> +
>> +static int anfc_wait_for_event(struct anfc *nfc, u32 event)
>> +{
>> + struct completion *comp;
>> + int ret;
>> +
>> + if (event == XFER_COMPLETE)
>> + comp = >xfercomp;
>> + else
>> + comp = >bufrdy;
>> +
>> + ret = wait_for_completion_timeout(comp,
>> msecs_to_jiffies(EVNT_TIMEOUT));
>> +
>> + return ret;
>
> return func();
>
>> +}
>> +
>> +static inline void anfc_setpktszcnt(struct anfc *nfc, u32 pktsize,
>> + u32 pktcount)
>> +{
>> + writel(pktsize | (pktcount << PKT_CNT_SHIFT), nfc->base +
>> PKT_OFST);
>> +}
>> +
>> +static inline void anfc_set_eccsparecmd(struct anfc *nfc, u8 cmd1,
>> u8 cmd2)
>> +{
>> + writel(cmd1 | (cmd2 << CMD2_SHIFT) |
>> +(nfc->caddr_cycles << ADDR_CYCLES_SHIFT),
>> +nfc->base + ECC_SPR_CMD_OFST);
>> +}
>> +
>> +static void anfc_setpagecoladdr(struct anfc *nfc, u32 page, u16 col)
>> +{
>> + u32 val;
>> +
>> + writel(col | (page << PG_ADDR_SHIFT), nfc->base +
>> MEM_ADDR1_OFST);
>> +
>> + val = readl(nfc->base + MEM_ADDR2_OFST);
>> + val = (val & ~MEM_ADDR_MASK) |
>> + ((page >> PG_ADDR_SHIFT) & MEM_ADDR_MASK);
>> + writel(val, nfc->base + MEM_ADDR2_OFST);
>> +}
>> +
>> +static void anfc_prepare_cmd(struct anfc *nfc, u8 cmd1, u8 cmd2,
>> + u8 dmamode, u32 pagesize, u8
>> addrcycles)
>> +{
>> + u32 regval;
>> +
>> + regval = cmd1 | (cmd2 << CMD2_SHIFT);
>> + if (dmamode && nfc->dma)
>> + regval |= DMA_ENABLE << DMA_EN_SHIFT;
>> + if (addrcycles)
>> + regval |= addrcycles << ADDR_CYCLES_SHIFT;
>> + if (pagesize)
>> + regval |= anfc_page(pagesize) << PAGE_SIZE_SHIFT;
>> + writel(regval, nfc->base + CMD_OFST);
>> +}
>> +
>> +static int anfc_device_ready(struct mtd_info *mtd,
>> + struct nand_chip *chip)
>> +{
>> + u8 status;
>> + unsigned long timeout = jiffies + STATUS_TIMEOUT;
>> +
>> + do {
>> + chip->cmdfunc(mtd, NAND_CMD_STATUS, 0, 0);
>> + status = chip->read_byte(mtd);
>> + if (status & ONFI_STATUS_READY) {
>
>> + if (status & ONFI_STATUS_FAIL)
>> + return NAND_STATUS_FAIL;
>
> This is invariant to
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko wrote: > On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote: >> Added the basic driver for Arasan Nand Flash Controller used in >> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit >> correction. >> > >> +config MTD_NAND_ARASAN >> + tristate "Support for Arasan Nand Flash controller" >> + depends on MTD_NAND > > This looks useless since you can't see the item without MTD_NAND is > chosen. > >> + help >> + Enables the driver for the Arasan Nand Flash controller on >> + Zynq UltraScale+ MPSoC. >> + >> endif # MTD_NAND >> > > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o > > "nfc" part a bit ambiguous since NFC might be Near Field Communication. This driver is under mtd/nand so, there is no point of confusion and in this context nfc is nand flash controller. > > Perhaps "nand_fc" or something like that? > >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o >> diff --git a/drivers/mtd/nand/arasan_nfc.c >> b/drivers/mtd/nand/arasan_nfc.c >> new file mode 100644 >> index 000..9d4665e >> --- /dev/null >> +++ b/drivers/mtd/nand/arasan_nfc.c >> @@ -0,0 +1,1026 @@ >> +/* >> + * Arasan Nand Flash Controller Driver >> + * >> + * Copyright (C) 2014 - 2015 Xilinx, Inc. >> + * >> + * This program is free software; you can redistribute it and/or >> modify it under >> + * the terms of the GNU General Public License version 2 as >> published by the >> + * Free Software Foundation; either version 2 of the License, or (at >> your >> + * option) any later version. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define DRIVER_NAME "arasan_nfc" > > Ditto. > >> +#define EVNT_TIMEOUT 1000 >> +#define STATUS_TIMEOUT 2000 >> + >> +#define PKT_OFST 0x00 >> +#define MEM_ADDR1_OFST 0x04 >> +#define MEM_ADDR2_OFST 0x08 >> +#define CMD_OFST 0x0C >> +#define PROG_OFST0x10 >> +#define INTR_STS_EN_OFST 0x14 >> +#define INTR_SIG_EN_OFST 0x18 >> +#define INTR_STS_OFST0x1C >> +#define READY_STS_OFST 0x20 >> +#define DMA_ADDR1_OFST 0x24 >> +#define FLASH_STS_OFST 0x28 >> +#define DATA_PORT_OFST 0x30 >> +#define ECC_OFST 0x34 >> +#define ECC_ERR_CNT_OFST 0x38 >> +#define ECC_SPR_CMD_OFST 0x3C >> +#define ECC_ERR_CNT_1BIT_OFST0x40 >> +#define ECC_ERR_CNT_2BIT_OFST0x44 >> +#define DMA_ADDR0_OFST 0x50 >> +#define DATA_INTERFACE_REG 0x6C >> + >> +#define PKT_CNT_SHIFT12 >> + >> +#define ECC_ENABLE BIT(31) >> +#define DMA_EN_MASK GENMASK(27, 26) >> +#define DMA_ENABLE 0x2 >> +#define DMA_EN_SHIFT 26 >> +#define PAGE_SIZE_MASK GENMASK(25, 23) > > PAGE_SIZE_ prefix is too broad, might conflict with global definitions > on some architectures. > >> +#define PAGE_SIZE_SHIFT 23 >> +#define PAGE_SIZE_5120 >> +#define PAGE_SIZE_1K 5 >> +#define PAGE_SIZE_2K 1 >> +#define PAGE_SIZE_4K 2 >> +#define PAGE_SIZE_8K 3 >> +#define PAGE_SIZE_16K4 >> +#define CMD2_SHIFT 8 >> +#define ADDR_CYCLES_SHIFT28 >> + >> +#define XFER_COMPLETEBIT(2) >> +#define READ_READY BIT(1) >> +#define WRITE_READY BIT(0) >> +#define MBIT_ERROR BIT(3) >> +#define ERR_INTRPT BIT(4) >> + >> +#define PROG_PGRDBIT(0) >> +#define PROG_ERASE BIT(2) >> +#define PROG_STATUS BIT(3) >> +#define PROG_PGPROG BIT(4) >> +#define PROG_RDIDBIT(6) >> +#define PROG_RDPARAM BIT(7) >> +#def
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko
<andriy.shevche...@linux.intel.com> wrote:
> On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote:
>> Added the basic driver for Arasan Nand Flash Controller used in
>> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit
>> correction.
>>
>
>> +config MTD_NAND_ARASAN
>> + tristate "Support for Arasan Nand Flash controller"
>> + depends on MTD_NAND
>
> This looks useless since you can't see the item without MTD_NAND is
> chosen.
>
>> + help
>> + Enables the driver for the Arasan Nand Flash controller on
>> + Zynq UltraScale+ MPSoC.
>> +
>> endif # MTD_NAND
>>
>
> +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o
>
> "nfc" part a bit ambiguous since NFC might be Near Field Communication.
>
> Perhaps "nand_fc" or something like that?
>
This driver is under mtd/nand so, there is no point of confusion here and
in this context nfc is nand flash controller.
>> +static u8 anfc_page(u32 pagesize)
>> +{
>> + switch (pagesize) {
>> + case 512:
>> + return PAGE_SIZE_512;
>> + case 2048:
>> + return PAGE_SIZE_2K;
>> + case 4096:
>> + return PAGE_SIZE_4K;
>> + case 8192:
>> + return PAGE_SIZE_8K;
>> + case 16384:
>> + return PAGE_SIZE_16K;
>> + case 1024:
>
> Why not keep sorted here?
>
It is sorted based on the return value. I will change the
sorting order based on the page size bytes.
>> + return PAGE_SIZE_1K;
>> + default:
>> + break;
>> + }
>> +
>> + return 0;
>
>
>
>> +}
>> +
>> +static inline void anfc_enable_intrs(struct anfc *nfc, u32 val)
>> +{
>> + writel(val, nfc->base + INTR_STS_EN_OFST);
>> + writel(val, nfc->base + INTR_SIG_EN_OFST);
>> +}
>> +
>> +static int anfc_wait_for_event(struct anfc *nfc, u32 event)
>> +{
>> + struct completion *comp;
>> + int ret;
>> +
>> + if (event == XFER_COMPLETE)
>> + comp = >xfercomp;
>> + else
>> + comp = >bufrdy;
>> +
>> + ret = wait_for_completion_timeout(comp,
>> msecs_to_jiffies(EVNT_TIMEOUT));
>> +
>> + return ret;
>
> return func();
>
>> +}
>> +
>> +static inline void anfc_setpktszcnt(struct anfc *nfc, u32 pktsize,
>> + u32 pktcount)
>> +{
>> + writel(pktsize | (pktcount << PKT_CNT_SHIFT), nfc->base +
>> PKT_OFST);
>> +}
>> +
>> +static inline void anfc_set_eccsparecmd(struct anfc *nfc, u8 cmd1,
>> u8 cmd2)
>> +{
>> + writel(cmd1 | (cmd2 << CMD2_SHIFT) |
>> +(nfc->caddr_cycles << ADDR_CYCLES_SHIFT),
>> +nfc->base + ECC_SPR_CMD_OFST);
>> +}
>> +
>> +static void anfc_setpagecoladdr(struct anfc *nfc, u32 page, u16 col)
>> +{
>> + u32 val;
>> +
>> + writel(col | (page << PG_ADDR_SHIFT), nfc->base +
>> MEM_ADDR1_OFST);
>> +
>> + val = readl(nfc->base + MEM_ADDR2_OFST);
>> + val = (val & ~MEM_ADDR_MASK) |
>> + ((page >> PG_ADDR_SHIFT) & MEM_ADDR_MASK);
>> + writel(val, nfc->base + MEM_ADDR2_OFST);
>> +}
>> +
>> +static void anfc_prepare_cmd(struct anfc *nfc, u8 cmd1, u8 cmd2,
>> + u8 dmamode, u32 pagesize, u8
>> addrcycles)
>> +{
>> + u32 regval;
>> +
>> + regval = cmd1 | (cmd2 << CMD2_SHIFT);
>> + if (dmamode && nfc->dma)
>> + regval |= DMA_ENABLE << DMA_EN_SHIFT;
>> + if (addrcycles)
>> + regval |= addrcycles << ADDR_CYCLES_SHIFT;
>> + if (pagesize)
>> + regval |= anfc_page(pagesize) << PAGE_SIZE_SHIFT;
>> + writel(regval, nfc->base + CMD_OFST);
>> +}
>> +
>> +static int anfc_device_ready(struct mtd_info *mtd,
>> + struct nand_chip *chip)
>> +{
>> + u8 status;
>> + unsigned long timeout = jiffies + STATUS_TIMEOUT;
>> +
>> + do {
>> + chip->cmdfunc(mtd, NAND_CMD_STATUS, 0, 0);
>> + status = chip->read_byte(mtd);
>> + if (status & ONFI_STATUS_READY) {
>
>> + if (status & ONFI_STATUS_FAIL)
>> + return NAN
Re: [PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
On Mon, Nov 9, 2015 at 7:20 PM, Andy Shevchenko <andriy.shevche...@linux.intel.com> wrote: > On Thu, 2015-11-05 at 08:19 +0530, Punnaiah Choudary Kalluri wrote: >> Added the basic driver for Arasan Nand Flash Controller used in >> Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit >> correction. >> > >> +config MTD_NAND_ARASAN >> + tristate "Support for Arasan Nand Flash controller" >> + depends on MTD_NAND > > This looks useless since you can't see the item without MTD_NAND is > chosen. > >> + help >> + Enables the driver for the Arasan Nand Flash controller on >> + Zynq UltraScale+ MPSoC. >> + >> endif # MTD_NAND >> > > +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o > > "nfc" part a bit ambiguous since NFC might be Near Field Communication. This driver is under mtd/nand so, there is no point of confusion and in this context nfc is nand flash controller. > > Perhaps "nand_fc" or something like that? > >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o >> diff --git a/drivers/mtd/nand/arasan_nfc.c >> b/drivers/mtd/nand/arasan_nfc.c >> new file mode 100644 >> index 000..9d4665e >> --- /dev/null >> +++ b/drivers/mtd/nand/arasan_nfc.c >> @@ -0,0 +1,1026 @@ >> +/* >> + * Arasan Nand Flash Controller Driver >> + * >> + * Copyright (C) 2014 - 2015 Xilinx, Inc. >> + * >> + * This program is free software; you can redistribute it and/or >> modify it under >> + * the terms of the GNU General Public License version 2 as >> published by the >> + * Free Software Foundation; either version 2 of the License, or (at >> your >> + * option) any later version. >> + */ >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#define DRIVER_NAME "arasan_nfc" > > Ditto. > >> +#define EVNT_TIMEOUT 1000 >> +#define STATUS_TIMEOUT 2000 >> + >> +#define PKT_OFST 0x00 >> +#define MEM_ADDR1_OFST 0x04 >> +#define MEM_ADDR2_OFST 0x08 >> +#define CMD_OFST 0x0C >> +#define PROG_OFST0x10 >> +#define INTR_STS_EN_OFST 0x14 >> +#define INTR_SIG_EN_OFST 0x18 >> +#define INTR_STS_OFST0x1C >> +#define READY_STS_OFST 0x20 >> +#define DMA_ADDR1_OFST 0x24 >> +#define FLASH_STS_OFST 0x28 >> +#define DATA_PORT_OFST 0x30 >> +#define ECC_OFST 0x34 >> +#define ECC_ERR_CNT_OFST 0x38 >> +#define ECC_SPR_CMD_OFST 0x3C >> +#define ECC_ERR_CNT_1BIT_OFST0x40 >> +#define ECC_ERR_CNT_2BIT_OFST0x44 >> +#define DMA_ADDR0_OFST 0x50 >> +#define DATA_INTERFACE_REG 0x6C >> + >> +#define PKT_CNT_SHIFT12 >> + >> +#define ECC_ENABLE BIT(31) >> +#define DMA_EN_MASK GENMASK(27, 26) >> +#define DMA_ENABLE 0x2 >> +#define DMA_EN_SHIFT 26 >> +#define PAGE_SIZE_MASK GENMASK(25, 23) > > PAGE_SIZE_ prefix is too broad, might conflict with global definitions > on some architectures. > >> +#define PAGE_SIZE_SHIFT 23 >> +#define PAGE_SIZE_5120 >> +#define PAGE_SIZE_1K 5 >> +#define PAGE_SIZE_2K 1 >> +#define PAGE_SIZE_4K 2 >> +#define PAGE_SIZE_8K 3 >> +#define PAGE_SIZE_16K4 >> +#define CMD2_SHIFT 8 >> +#define ADDR_CYCLES_SHIFT28 >> + >> +#define XFER_COMPLETEBIT(2) >> +#define READ_READY BIT(1) >> +#define WRITE_READY BIT(0) >> +#define MBIT_ERROR BIT(3) >> +#define ERR_INTRPT BIT(4) >> + >> +#define PROG_PGRDBIT(0) >> +#define PROG_ERASE BIT(2) >> +#define PROG_STATUS BIT(3) >> +#define PROG_PGPROG BIT(4) >> +#define PROG_RDIDBIT(6) >> +#define PROG
Re: [PATCH v4 1/3] mtd: arasan: Add device tree binding documentation
On Fri, Nov 6, 2015 at 5:19 AM, Rob Herring wrote: > On Thu, Nov 05, 2015 at 08:18:42AM +0530, Punnaiah Choudary Kalluri wrote: >> This patch adds the dts binding document for arasan nand flash >> controller. >> >> Signed-off-by: Punnaiah Choudary Kalluri >> --- >> Changes in v4: >> - Added num-cs property >> - Added clock support >> Changes in v3: >> - None >> Changes in v2: >> - None >> --- >> .../devicetree/bindings/mtd/arasan_nfc.txt | 34 >> ++ >> 1 file changed, 34 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> >> diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> new file mode 100644 >> index 000..02e1ce3 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> @@ -0,0 +1,34 @@ >> +Arasan Nand Flash Controller with ONFI 3.1 support >> + >> +Required properties: >> +- compatible: Should be "arasan,nfc-v3p10" > > There should also be a chip specific property. Vendors are known to > integrate IP blocks in different and interesting ways. This IP used in xilinx Zynq UltraScale+ MPSoC and we have not observed any deviations to the original IP as of today. We will add chip specific property if we observe any deviation to the original IP spec. Regards, Punnaiah > > Rob -- 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/
[PATCH] mtd: Expand the ecc placement locations to 1216
Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes.
So, increasing the maximum ecc placement locations to 1216
Signed-off-by: Punnaiah Choudary Kalluri
---
include/linux/mtd/mtd.h| 2 +-
include/uapi/mtd/mtd-abi.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index f17fa75..1fd3cc6 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -95,7 +95,7 @@ struct mtd_oob_ops {
};
#define MTD_MAX_OOBFREE_ENTRIES_LARGE 32
-#define MTD_MAX_ECCPOS_ENTRIES_LARGE 640
+#define MTD_MAX_ECCPOS_ENTRIES_LARGE 1216
/*
* Internal ECC layout control structure. For historical reasons, there is a
* similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is retained
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 763bb69..c4d592c 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -220,8 +220,8 @@ struct nand_oobfree {
__u32 length;
};
-#define MTD_MAX_OOBFREE_ENTRIES8
-#define MTD_MAX_ECCPOS_ENTRIES 64
+#define MTD_MAX_OOBFREE_ENTRIES32
+#define MTD_MAX_ECCPOS_ENTRIES 1216
/*
* OBSOLETE: ECC layout control structure. Exported to user-space via ioctl
* ECCGETLAYOUT for backwards compatbility and should not be mistaken as a
--
2.1.2
--
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/
[PATCH] mtd: Expand the ecc placement locations to 1216
Device like MT29F32G08ABCDBJ4 have a writesize/oobsize of 16K/1216 Bytes.
So, increasing the maximum ecc placement locations to 1216
Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
---
include/linux/mtd/mtd.h| 2 +-
include/uapi/mtd/mtd-abi.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index f17fa75..1fd3cc6 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -95,7 +95,7 @@ struct mtd_oob_ops {
};
#define MTD_MAX_OOBFREE_ENTRIES_LARGE 32
-#define MTD_MAX_ECCPOS_ENTRIES_LARGE 640
+#define MTD_MAX_ECCPOS_ENTRIES_LARGE 1216
/*
* Internal ECC layout control structure. For historical reasons, there is a
* similar, smaller struct nand_ecclayout_user (in mtd-abi.h) that is retained
diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
index 763bb69..c4d592c 100644
--- a/include/uapi/mtd/mtd-abi.h
+++ b/include/uapi/mtd/mtd-abi.h
@@ -220,8 +220,8 @@ struct nand_oobfree {
__u32 length;
};
-#define MTD_MAX_OOBFREE_ENTRIES8
-#define MTD_MAX_ECCPOS_ENTRIES 64
+#define MTD_MAX_OOBFREE_ENTRIES32
+#define MTD_MAX_ECCPOS_ENTRIES 1216
/*
* OBSOLETE: ECC layout control structure. Exported to user-space via ioctl
* ECCGETLAYOUT for backwards compatbility and should not be mistaken as a
--
2.1.2
--
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/
Re: [PATCH v4 1/3] mtd: arasan: Add device tree binding documentation
On Fri, Nov 6, 2015 at 5:19 AM, Rob Herring <r...@kernel.org> wrote: > On Thu, Nov 05, 2015 at 08:18:42AM +0530, Punnaiah Choudary Kalluri wrote: >> This patch adds the dts binding document for arasan nand flash >> controller. >> >> Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> >> --- >> Changes in v4: >> - Added num-cs property >> - Added clock support >> Changes in v3: >> - None >> Changes in v2: >> - None >> --- >> .../devicetree/bindings/mtd/arasan_nfc.txt | 34 >> ++ >> 1 file changed, 34 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> >> diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> new file mode 100644 >> index 000..02e1ce3 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> @@ -0,0 +1,34 @@ >> +Arasan Nand Flash Controller with ONFI 3.1 support >> + >> +Required properties: >> +- compatible: Should be "arasan,nfc-v3p10" > > There should also be a chip specific property. Vendors are known to > integrate IP blocks in different and interesting ways. This IP used in xilinx Zynq UltraScale+ MPSoC and we have not observed any deviations to the original IP as of today. We will add chip specific property if we observe any deviation to the original IP spec. Regards, Punnaiah > > Rob -- 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/
[PATCH v4 3/3] mtd: nand: Add macro definition for nvddr interface mode
Added macro definition for nvddr data interface mode field in the sub feature parameter of onfi timing mode configuration. Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v4: - New change --- include/linux/mtd/nand.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 272f429..1085604 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -215,6 +215,9 @@ struct nand_chip; #define ONFI_TIMING_MODE_5 (1 << 5) #define ONFI_TIMING_MODE_UNKNOWN (1 << 6) +/* ONFI data interface mode */ +#define ONFI_DATA_INTERFACE_NVDDR (1 << 4) + /* ONFI feature address */ #define ONFI_FEATURE_ADDR_TIMING_MODE 0x1 -- 2.1.2 -- 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/
[PATCH v4 1/3] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri
---
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..02e1ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,34 @@
+Arasan Nand Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables Dma support
+- num-cs: Number of chip selects used
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ num-cs = <1>;
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
--
2.1.2
--
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/
[PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Added the basic driver for Arasan Nand Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report error --- drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/arasan_nfc.c | 1026 + 3 files changed, 1034 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nfc.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 3324281..af9b274 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -535,4 +535,11 @@ config MTD_NAND_HISI504 help Enables support for NAND controller on Hisilicon SoC Hip04. +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + depends on MTD_NAND + help + Enables the driver for the Arasan Nand Flash controller on + Zynq UltraScale+ MPSoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 075a027..ab07ea8 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -54,5 +54,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/arasan_nfc.c b/drivers/mtd/nand/arasan_nfc.c new file mode 100644 index 000..9d4665e --- /dev/null +++ b/drivers/mtd/nand/arasan_nfc.c @@ -0,0 +1,1026 @@ +/* + * Arasan Nand Flash Controller Driver + * + * Copyright (C) 2014 - 2015 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nfc" +#define EVNT_TIMEOUT 1000 +#define STATUS_TIMEOUT 2000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_REG 0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENABLE BIT(31) +#define DMA_EN_MASKGENMASK(27, 26) +#define DMA_ENABLE 0x2 +#define DMA_EN_SHIFT 26 +#define PAGE_SIZE_MASK GENMASK(25, 23) +#define PAGE_SIZE_SHIFT23 +#define PAGE_SIZE_512 0 +#define PAGE_SIZE_1K 5 +#define PAGE_SIZE_2K 1 +#define PAGE_SIZE_4K 2 +#define PAGE_SIZE_8K 3 +#define PAGE_SIZE_16K 4 +#define CMD2_SHIFT 8 +#define ADDR_CYCLES_SHIFT 28 + +#define XFER_COMPLETE BIT(2) +#define READ_READY BIT(1) +#define WRITE_READYBIT(0) +#define MBIT_ERROR BIT(3) +#define ERR_INTRPT BIT(4) + +#define PROG_PGRD BIT(0) +#define PROG_ERASE BIT(2) +#define PROG_STATUSBIT(3) +#define PROG_PGPROGBIT(4) +#define PROG_RDID BIT(6) +#define PROG_RDPARAM BIT(7) +#define PROG_RST BIT(8) +#define PROG_GET_FEATURE
[PATCH v4 2/3] mtd: nand: Add support for Arasan Nand Flash Controller
Added the basic driver for Arasan Nand Flash Controller used in Zynq UltraScale+ MPSoC. It supports only Hw Ecc and upto 24bit correction. Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> --- Changes in v4: - Added support for onfi timing mode configuration - Added clock suort - Added support for multiple chipselects Changes in v3: - Removed unused variables - Avoided busy loop and used jifies based implementation - Fixed compiler warnings "right shift count >= width of type" - Removed unneeded codei and improved error reporting - Added onfi version check to ensure reading the valid address cycles Changes in v2: - Added missing of.h to avoid kbuild system report error --- drivers/mtd/nand/Kconfig |7 + drivers/mtd/nand/Makefile |1 + drivers/mtd/nand/arasan_nfc.c | 1026 + 3 files changed, 1034 insertions(+) create mode 100644 drivers/mtd/nand/arasan_nfc.c diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 3324281..af9b274 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -535,4 +535,11 @@ config MTD_NAND_HISI504 help Enables support for NAND controller on Hisilicon SoC Hip04. +config MTD_NAND_ARASAN + tristate "Support for Arasan Nand Flash controller" + depends on MTD_NAND + help + Enables the driver for the Arasan Nand Flash controller on + Zynq UltraScale+ MPSoC. + endif # MTD_NAND diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 075a027..ab07ea8 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -54,5 +54,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/ obj-$(CONFIG_MTD_NAND_SUNXI) += sunxi_nand.o obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ +obj-$(CONFIG_MTD_NAND_ARASAN) += arasan_nfc.o nand-objs := nand_base.o nand_bbt.o nand_timings.o diff --git a/drivers/mtd/nand/arasan_nfc.c b/drivers/mtd/nand/arasan_nfc.c new file mode 100644 index 000..9d4665e --- /dev/null +++ b/drivers/mtd/nand/arasan_nfc.c @@ -0,0 +1,1026 @@ +/* + * Arasan Nand Flash Controller Driver + * + * Copyright (C) 2014 - 2015 Xilinx, Inc. + * + * This program is free software; you can redistribute it and/or modify it under + * the terms of the GNU General Public License version 2 as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define DRIVER_NAME"arasan_nfc" +#define EVNT_TIMEOUT 1000 +#define STATUS_TIMEOUT 2000 + +#define PKT_OFST 0x00 +#define MEM_ADDR1_OFST 0x04 +#define MEM_ADDR2_OFST 0x08 +#define CMD_OFST 0x0C +#define PROG_OFST 0x10 +#define INTR_STS_EN_OFST 0x14 +#define INTR_SIG_EN_OFST 0x18 +#define INTR_STS_OFST 0x1C +#define READY_STS_OFST 0x20 +#define DMA_ADDR1_OFST 0x24 +#define FLASH_STS_OFST 0x28 +#define DATA_PORT_OFST 0x30 +#define ECC_OFST 0x34 +#define ECC_ERR_CNT_OFST 0x38 +#define ECC_SPR_CMD_OFST 0x3C +#define ECC_ERR_CNT_1BIT_OFST 0x40 +#define ECC_ERR_CNT_2BIT_OFST 0x44 +#define DMA_ADDR0_OFST 0x50 +#define DATA_INTERFACE_REG 0x6C + +#define PKT_CNT_SHIFT 12 + +#define ECC_ENABLE BIT(31) +#define DMA_EN_MASKGENMASK(27, 26) +#define DMA_ENABLE 0x2 +#define DMA_EN_SHIFT 26 +#define PAGE_SIZE_MASK GENMASK(25, 23) +#define PAGE_SIZE_SHIFT23 +#define PAGE_SIZE_512 0 +#define PAGE_SIZE_1K 5 +#define PAGE_SIZE_2K 1 +#define PAGE_SIZE_4K 2 +#define PAGE_SIZE_8K 3 +#define PAGE_SIZE_16K 4 +#define CMD2_SHIFT 8 +#define ADDR_CYCLES_SHIFT 28 + +#define XFER_COMPLETE BIT(2) +#define READ_READY BIT(1) +#define WRITE_READYBIT(0) +#define MBIT_ERROR BIT(3) +#define ERR_INTRPT BIT(4) + +#define PROG_PGRD BIT(0) +#define PROG_ERASE BIT(2) +#define PROG_STATUSBIT(3) +#define PROG_PGPROGBIT(4) +#define PROG_RDID BIT(6) +#define PROG_RDPARAM BIT(7) +#define PROG_RST BIT(8) +#define PROG_GE
[PATCH v4 1/3] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com>
---
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..02e1ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,34 @@
+Arasan Nand Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables Dma support
+- num-cs: Number of chip selects used
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <_clk _clk>;
+ interrupt-parent = <>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ num-cs = <1>;
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
--
2.1.2
--
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/
[PATCH v4 3/3] mtd: nand: Add macro definition for nvddr interface mode
Added macro definition for nvddr data interface mode field in the sub feature parameter of onfi timing mode configuration. Signed-off-by: Punnaiah Choudary Kalluri <punn...@xilinx.com> --- Changes in v4: - New change --- include/linux/mtd/nand.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 272f429..1085604 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -215,6 +215,9 @@ struct nand_chip; #define ONFI_TIMING_MODE_5 (1 << 5) #define ONFI_TIMING_MODE_UNKNOWN (1 << 6) +/* ONFI data interface mode */ +#define ONFI_DATA_INTERFACE_NVDDR (1 << 4) + /* ONFI feature address */ #define ONFI_FEATURE_ADDR_TIMING_MODE 0x1 -- 2.1.2 -- 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/
Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver
On Wed, Sep 30, 2015 at 9:48 PM, Felipe Balbi wrote:
> On Thu, Sep 24, 2015 at 11:18:01AM -0500, Rob Herring wrote:
>> On Thu, Sep 24, 2015 at 4:26 AM, Subbaraya Sundeep Bhatta
>> wrote:
>> > Hi Peter,
>> >
>> >> -Original Message-
>> >> From: Peter Chen [mailto:peter.c...@freescale.com]
>> >> Sent: Thursday, September 24, 2015 2:41 PM
>> >> To: Subbaraya Sundeep Bhatta
>> >> Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@ti.com;
>> >> gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
>> >> ker...@vger.kernel.org; Punnaiah Choudary Kalluri; Subbaraya Sundeep
>> >> Bhatta;
>> >> linux-arm-ker...@lists.infradead.org
>> >> Subject: Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform
>> >> driver
>> >>
>> >> On Wed, Sep 23, 2015 at 06:24:01PM +0530, Subbaraya Sundeep Bhatta
>> >> wrote:
>> >> > This patch adds binding doc info for generic ULPI PHYs platform
>> >> > driver.
>> >> >
>> >> > Signed-off-by: Subbaraya Sundeep Bhatta
>> >> > ---
>> >> > .../devicetree/bindings/usb/ulpi-platform-phy.txt | 34
>> >>
>> >> > 1 files changed, 34 insertions(+), 0 deletions(-) create mode 100644
>> >> > Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> >
>> >> > diff --git
>> >> > a/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> > b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> > new file mode 100644
>> >> > index 000..7b8cbb4
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> > @@ -0,0 +1,34 @@
>> >> > +Platform driver for generic ULPI PHYs
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible : Should be "ulpi-phy"
>> >> > +- reg : Physical base address and size of the USB
>> >> > + controller registers map to which this PHY
>> >> > + is connected.
>> >> > +- view-port: Should contain viewport register offset
>> >> > of the
>> >> > + USB controller to which this PHY is connected
>> >> > Optional
>> >> > +properties:
>> >> > +- drv-vbus : required if turning VBUS on/off has to be driven
>> >> > + by writing to PHY. This feature depends on board
>> >> > + design.
>> >> > +
>> >> > +Example:
>> >> > +Below example shows the PHY binding for Chipidea USB controller which
>> >> > +has ulpi viewport register at 0x0170
>> >> > +
>> >> > + usb_phy0: phy0 {
>> >> > + compatible = "ulpi-phy";
>> >> > + reg = <0xe0002000 0x1000>;
>> >> > + view-port = <0x0170>;
>> >> > + drv-vbus;
>> >> > + };
>> >> > +
>> >> > + usb0: usb@e0002000 {
>> >> > +compatible = "chipidea,usb2";
>> >> > +interrupt-parent = <>;
>> >> > +interrupts = <0 21 4>;
>> >> > +reg = <0xe0002000 0x1000>;
>> >>
>> >> Although just call devm_ioremap twice for the same register region does
>> >> not
>> >> cause any errors, I am not sure if it will has other potential problems.
>> >> Cc: arm
>> >> list.
>> >
>> > Yes Peter I was also in doubt to call devm_ioremap twice for same register
>> > region.
>> > devm_ioremap_resource complained hence modified to devm_ioremap. Thanks for
>> > adding arm-list.
>>
>> Don't put overlapping resources in the DT. Having 2 drivers accessing
>> the same registers is not a clean or safe design.
>
> thanks, saves me the trouble of saying the same thing.
>
> Bottom line, if devm_ioremap_resource() fails, you're wrong. Just fix
> your driver and move on.
Any suggestions on how to move further?
Chipidea controller provides ulpi view port register for accessing the
usb phy registers. Now we want to add new driver for ulpi phy configuration
and that obviously it need of ulpi view port register access. So, sharing the
register space between these two drivers is necessary here.
Regards,
Punnaiah
>
> --
> balbi
--
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/
Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver
On Wed, Sep 30, 2015 at 9:48 PM, Felipe Balbi <ba...@ti.com> wrote:
> On Thu, Sep 24, 2015 at 11:18:01AM -0500, Rob Herring wrote:
>> On Thu, Sep 24, 2015 at 4:26 AM, Subbaraya Sundeep Bhatta
>> <subbaraya.sundeep.bha...@xilinx.com> wrote:
>> > Hi Peter,
>> >
>> >> -Original Message-
>> >> From: Peter Chen [mailto:peter.c...@freescale.com]
>> >> Sent: Thursday, September 24, 2015 2:41 PM
>> >> To: Subbaraya Sundeep Bhatta
>> >> Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@ti.com;
>> >> gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
>> >> ker...@vger.kernel.org; Punnaiah Choudary Kalluri; Subbaraya Sundeep
>> >> Bhatta;
>> >> linux-arm-ker...@lists.infradead.org
>> >> Subject: Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform
>> >> driver
>> >>
>> >> On Wed, Sep 23, 2015 at 06:24:01PM +0530, Subbaraya Sundeep Bhatta
>> >> wrote:
>> >> > This patch adds binding doc info for generic ULPI PHYs platform
>> >> > driver.
>> >> >
>> >> > Signed-off-by: Subbaraya Sundeep Bhatta <sbha...@xilinx.com>
>> >> > ---
>> >> > .../devicetree/bindings/usb/ulpi-platform-phy.txt | 34
>> >>
>> >> > 1 files changed, 34 insertions(+), 0 deletions(-) create mode 100644
>> >> > Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> >
>> >> > diff --git
>> >> > a/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> > b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> > new file mode 100644
>> >> > index 000..7b8cbb4
>> >> > --- /dev/null
>> >> > +++ b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
>> >> > @@ -0,0 +1,34 @@
>> >> > +Platform driver for generic ULPI PHYs
>> >> > +
>> >> > +Required properties:
>> >> > +- compatible : Should be "ulpi-phy"
>> >> > +- reg : Physical base address and size of the USB
>> >> > + controller registers map to which this PHY
>> >> > + is connected.
>> >> > +- view-port: Should contain viewport register offset
>> >> > of the
>> >> > + USB controller to which this PHY is connected
>> >> > Optional
>> >> > +properties:
>> >> > +- drv-vbus : required if turning VBUS on/off has to be driven
>> >> > + by writing to PHY. This feature depends on board
>> >> > + design.
>> >> > +
>> >> > +Example:
>> >> > +Below example shows the PHY binding for Chipidea USB controller which
>> >> > +has ulpi viewport register at 0x0170
>> >> > +
>> >> > + usb_phy0: phy0 {
>> >> > + compatible = "ulpi-phy";
>> >> > + reg = <0xe0002000 0x1000>;
>> >> > + view-port = <0x0170>;
>> >> > + drv-vbus;
>> >> > + };
>> >> > +
>> >> > + usb0: usb@e0002000 {
>> >> > +compatible = "chipidea,usb2";
>> >> > +interrupt-parent = <>;
>> >> > +interrupts = <0 21 4>;
>> >> > +reg = <0xe0002000 0x1000>;
>> >>
>> >> Although just call devm_ioremap twice for the same register region does
>> >> not
>> >> cause any errors, I am not sure if it will has other potential problems.
>> >> Cc: arm
>> >> list.
>> >
>> > Yes Peter I was also in doubt to call devm_ioremap twice for same register
>> > region.
>> > devm_ioremap_resource complained hence modified to devm_ioremap. Thanks for
>> > adding arm-list.
>>
>> Don't put overlapping resources in the DT. Having 2 drivers accessing
>> the same registers is not a clean or safe design.
>
> thanks, saves me the trouble of saying the same thing.
>
> Bottom line, if devm_ioremap_resource() fails, you're wrong. Just fix
> your driver and move on.
Any suggestions on how to move further?
Chipidea controller provides ulpi view port register for accessing the
usb phy registers. Now we want to add new driver for ulpi phy configuration
and that obviously it need of ulpi view port register access. So, sharing the
register space between these two drivers is necessary here.
Regards,
Punnaiah
>
> --
> balbi
--
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/
RE: Chipidea ULPI driver
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Thursday, September 10, 2015 8:14 PM > To: Subbaraya Sundeep Bhatta > Cc: Peter Chen; ba...@ti.com; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Greg Kroah-Hartman > (gre...@linuxfoundation.org); kis...@ti.com; Punnaiah Choudary Kalluri > Subject: Re: Chipidea ULPI driver > > (break your lines at 80-characters) > > On Thu, Sep 10, 2015 at 12:44:58PM +, Subbaraya Sundeep Bhatta wrote: > > Hi Peter, > > > > We are using NOP transceiver driver for USB3320 ULPI PHY with ChipIdea > > controller. > > > > Recently we found that one of the boards (zedboard) requires PHY > > register access to set VBUS. > > > > Note that our local driver we had before migrating to ChipIdea driver > > calls otg_ulpi_create with flags ULPI_OTG_DRVVBUS | > > ULPI_OTG_DRVVBUS_EXT so that VBUS is enabled at initialization. > > > > Can you please let me know how to do this with ChipIdea case? I see > > the following solutions: > > > > 1. Write ULPI driver for USB3320 similar to tusb1210. > > this How about extending the phy-ulpi driver to use it as platform driver? So that boards that are using the ulpi compatible phy and driving vbus from the phy can use this driver. Regards, Punnaiah > > > 2. Write ci_hdrc_zynq.c which does PHY access required for Zynq. > > not this > > -- > balbi -- 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/
RE: Chipidea ULPI driver
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Thursday, September 10, 2015 8:14 PM > To: Subbaraya Sundeep Bhatta > Cc: Peter Chen; ba...@ti.com; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Greg Kroah-Hartman > (gre...@linuxfoundation.org); kis...@ti.com; Punnaiah Choudary Kalluri > Subject: Re: Chipidea ULPI driver > > (break your lines at 80-characters) > > On Thu, Sep 10, 2015 at 12:44:58PM +, Subbaraya Sundeep Bhatta wrote: > > Hi Peter, > > > > We are using NOP transceiver driver for USB3320 ULPI PHY with ChipIdea > > controller. > > > > Recently we found that one of the boards (zedboard) requires PHY > > register access to set VBUS. > > > > Note that our local driver we had before migrating to ChipIdea driver > > calls otg_ulpi_create with flags ULPI_OTG_DRVVBUS | > > ULPI_OTG_DRVVBUS_EXT so that VBUS is enabled at initialization. > > > > Can you please let me know how to do this with ChipIdea case? I see > > the following solutions: > > > > 1. Write ULPI driver for USB3320 similar to tusb1210. > > this How about extending the phy-ulpi driver to use it as platform driver? So that boards that are using the ulpi compatible phy and driving vbus from the phy can use this driver. Regards, Punnaiah > > > 2. Write ci_hdrc_zynq.c which does PHY access required for Zynq. > > not this > > -- > balbi -- 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/
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Tue, Aug 25, 2015 at 12:16 PM, punnaiah choudary kalluri
wrote:
> Hi Rob,
>
> On Tue, Aug 25, 2015 at 12:23 AM, Rob Herring wrote:
>> On Wed, Aug 5, 2015 at 10:19 PM, Punnaiah Choudary Kalluri
>> wrote:
>>> Device-tree binding documentation for Xilinx zynqmp dma engine used in
>>> Zynq UltraScale+ MPSoC.
>>>
>>> Signed-off-by: Punnaiah Choudary Kalluri
>>> ---
>>> Changes in v4:
>>> - None
>>> Changes in v3:
>>> - None
>>> Changes in v2:
>>> - None
>>> ---
>>> .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61
>>>
>>> 1 files changed, 61 insertions(+), 0 deletions(-)
>>> create mode 100644
>>> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>> new file mode 100644
>>> index 000..e4f92b9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>> @@ -0,0 +1,61 @@
>>> +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
>>> +memory to device and device to memory transfers. It also has flow
>>> +control and rate control support for slave/peripheral dma access.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "xlnx,zynqmp-dma-1.0"
>>> +- #dma-cells: Should be <1>, a single cell holding a line request number
>>> +- reg: Memory map for module access
>>> +- interrupt-parent: Interrupt controller the interrupt is routed through
>>> +- interrupts: Should contain DMA channel interrupt
>>> +- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
>>> +
>>> +Optional properties:
>>> +- xlnx,include-sg: Indicates the controller to operate in simple or scatter
>>> + gather dma mode
>>> +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
>>> +source AXI transaction
>>> +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the
>>> data
>>> +- xlnx,src-issue: Number of AXI outstanding transactions on source side
>>> +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for
>>> the
>>> + descriptor read are marked Non-coherent
>>> +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
>>> + source descriptor payload are marked Non-coherent
>>> +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
>>> + dst descriptor payload are marked Non-coherent
>>
>> Do you really need 3? dma-coherent property doesn't work for you?
>>
>> Not that it should dictate the binding, but the kernel doesn't support
>> a device needing both coherent and non-coherent DMA ops.
>
> I will get back to you shortly on this
Yes. dma-coherent property works. I will modify the bindings.
Thanks,
Punnaiah
>
>>
>>> +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
>>> +- xlnx,src-axi-qos: AXI QOS bits to be used for data read
>>> +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
>>> +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
>>> +- xlnx,desc-axi-cache: AXI cache bits to be used for data read
>>> +- xlnx,desc-axi-cache: AXI cache bits to be used for data write
>>
>> These signals are generally part of the coherent or not setting. This
>> allows for potentially invalid combinations.
>>
>> Plus you have a copy/paste error.
>
> I will fix this.
>
> Thanks,
> Punnaiah
>>
>>> +- xlnx,src-burst-len: AXI length for data read. Support only power of 2
>>> values
>>> + i.e 1,2,4,8 and 16
>>> +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2
>>> values
>>> + i.e 1,2,4,8 and 16
>>> +
>>> +Example:
>>> +
>>> +fpd_dma_chan1: dma@FD50 {
>>> + compatible = "xlnx,zynqmp-dma-1.0";
>>> + reg = <0x0 0xFD50 0x1000>;
>>> + #dma_cells = <1>;
>>> + interrupt-parent = <>;
>>> + interrupts = <0 117 4>;
>>> + xlnx,bus-width = <128>;
>>> + xlnx,include-sg;
>>> + xlnx,overfetch;
>>> +
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
On Mon, Aug 31, 2015 at 6:10 AM, Peter Chen wrote: > On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote: >> On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote: >> > On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote: >> > > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri >> > > wrote: >> > > > Hi, >> > > > >> > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen >> > > > wrote: >> > > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: >> > > > >> Hi, >> > > > >> >> > > > >> >> > > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan >> > > > >> wrote: >> > > > >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING >> > > > >> > flag, >> > > > >> > unlike the default platform data. Add platform data specific to >> > > > >> > the >> > > > >> > Zynq udc. >> > > > >> > >> > > > >> > Based on a patch by the same name from the Xilinx vendor tree. >> > > > >> >> > > > >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree as >> > > > >> temporary fix and >> > > > >> I did not debug further why UDC works only when streaming is >> > > > >> enabled. >> > > > >> Probably this is right time to post my question here. >> > > > >> I was expecting like: >> > > > >> Streaming disabled - both low bandwidth and high bandwidth systems >> > > > >> should work fine >> > > > >> Streaming enabled - only for high bandwidth systems >> > > > >> but this is not the case, Zynq UDC works only when Streaming is >> > > > >> enabled. >> > > > >> Please correct me if I am wrong. >> > > > > >> > > > > You are right, stream mode disabled should work at anytime. >> > > > > It is so strange why zynq UDC only works when stream mode is enabled. >> > > > >> > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc >> > > > 2.20a, >> > > > this is what it says about SDIS (streaming mode disable option) >> > > > >> > > > Before activating this mode, the user must check if the TX latency >> > > > buffers per endpoint are able to >> > > > accommodate at least one entire maximum size packet. The RX buffer >> > > > size must, at least, double the TX >> > > > buffer size per endpoint. To optimize the stream disable performance, >> > > > system bus burst must be set as high >> > > > as possible. >> > > > When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST >> > > > and VUSB_HS_TX_BURST) >> > > > must be a integer sub-multiple of the latency buffer size >> > > > (VUSB_HS_RX_DEPTH for RX buffer and >> > > > VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the >> > > > controller will not work properly in stream >> > > > disable mode. >> > > > The stream disable mode should just be used in situations where the >> > > > available system bandwidth is low or the >> > > > system bus access latency is high, in order to avoid underruns and >> > > > overruns in the latency buffers. This works >> > > > for all types of endpoints, except for ISO endpoints. >> > > > Such a system can't ensure the real time support that the ISO >> > > > endpoints require, so the ISO endpoints are not >> > > > supported when the SDIS bit is set. >> > > > >> > > > Definitely we need to root cause why disable streaming mode is not >> > > > working for zynq but from controller spec >> > > > point of view it is possible that controller not work properly in >> > > > stream disable mode. >> > > > >> > > > Regards, >> > > > Punnaiah >> > > > >> > > >> > > Maybe the burst size isn't set correctly by default? It does say the >> > > controller >> > > won't work correctly with stream disable set and an invalid burst size. >> >
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Tue, Aug 25, 2015 at 12:16 PM, punnaiah choudary kalluri
punn...@xilinx.com wrote:
Hi Rob,
On Tue, Aug 25, 2015 at 12:23 AM, Rob Herring robherri...@gmail.com wrote:
On Wed, Aug 5, 2015 at 10:19 PM, Punnaiah Choudary Kalluri
punnaiah.choudary.kall...@xilinx.com wrote:
Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..e4f92b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,61 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible: Should be xlnx,zynqmp-dma-1.0
+- #dma-cells: Should be 1, a single cell holding a line request number
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain DMA channel interrupt
+- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
+
+Optional properties:
+- xlnx,include-sg: Indicates the controller to operate in simple or scatter
+ gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
+source AXI transaction
+- xlnx,overfetch: Tells whether the channel is allowed to over fetch the
data
+- xlnx,src-issue: Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for
the
+ descriptor read are marked Non-coherent
+- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
+ source descriptor payload are marked Non-coherent
+- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
+ dst descriptor payload are marked Non-coherent
Do you really need 3? dma-coherent property doesn't work for you?
Not that it should dictate the binding, but the kernel doesn't support
a device needing both coherent and non-coherent DMA ops.
I will get back to you shortly on this
Yes. dma-coherent property works. I will modify the bindings.
Thanks,
Punnaiah
+- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
+- xlnx,src-axi-qos: AXI QOS bits to be used for data read
+- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
+- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
+- xlnx,desc-axi-cache: AXI cache bits to be used for data read
+- xlnx,desc-axi-cache: AXI cache bits to be used for data write
These signals are generally part of the coherent or not setting. This
allows for potentially invalid combinations.
Plus you have a copy/paste error.
I will fix this.
Thanks,
Punnaiah
+- xlnx,src-burst-len: AXI length for data read. Support only power of 2
values
+ i.e 1,2,4,8 and 16
+- xlnx,dst-burst-len: AXI length for data write. Support only power of 2
values
+ i.e 1,2,4,8 and 16
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+ compatible = xlnx,zynqmp-dma-1.0;
+ reg = 0x0 0xFD50 0x1000;
+ #dma_cells = 1;
+ interrupt-parent = gic;
+ interrupts = 0 117 4;
+ xlnx,bus-width = 128;
+ xlnx,include-sg;
+ xlnx,overfetch;
+ xlnx,ratectrl = 0;
+ xlnx,src-issue = 16;
+ xlnx,desc-axi-cohrnt;
+ xlnx,src-axi-cohrnt;
+ xlnx,dst-axi-cohrnt;
+ xlnx,desc-axi-qos = 0;
+ xlnx,desc-axi-cache = 0;
+ xlnx,src-axi-qos = 0;
+ xlnx,src-axi-cache = 2;
+ xlnx,dst-axi-qos = 0;
+ xlnx,dst-axi-cache = 2;
+ xlnx,src-burst-len = 4;
+ xlnx,dst-burst-len = 4;
+};
--
1.7.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
On Mon, Aug 31, 2015 at 6:10 AM, Peter Chen peter.c...@freescale.com wrote: On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote: On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote: On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote: On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary kalluri wrote: Hi, On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen peter.c...@freescale.com wrote: On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: Hi, On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan nathan.sulli...@ni.com wrote: The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag, unlike the default platform data. Add platform data specific to the Zynq udc. Based on a patch by the same name from the Xilinx vendor tree. I am that Xilinx guy who sent this patch :). It is in Xilinx tree as temporary fix and I did not debug further why UDC works only when streaming is enabled. Probably this is right time to post my question here. I was expecting like: Streaming disabled - both low bandwidth and high bandwidth systems should work fine Streaming enabled - only for high bandwidth systems but this is not the case, Zynq UDC works only when Streaming is enabled. Please correct me if I am wrong. You are right, stream mode disabled should work at anytime. It is so strange why zynq UDC only works when stream mode is enabled. I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc 2.20a, this is what it says about SDIS (streaming mode disable option) Before activating this mode, the user must check if the TX latency buffers per endpoint are able to accommodate at least one entire maximum size packet. The RX buffer size must, at least, double the TX buffer size per endpoint. To optimize the stream disable performance, system bus burst must be set as high as possible. When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a integer sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the controller will not work properly in stream disable mode. The stream disable mode should just be used in situations where the available system bandwidth is low or the system bus access latency is high, in order to avoid underruns and overruns in the latency buffers. This works for all types of endpoints, except for ISO endpoints. Such a system can't ensure the real time support that the ISO endpoints require, so the ISO endpoints are not supported when the SDIS bit is set. Definitely we need to root cause why disable streaming mode is not working for zynq but from controller spec point of view it is possible that controller not work properly in stream disable mode. Regards, Punnaiah Maybe the burst size isn't set correctly by default? It does say the controller won't work correctly with stream disable set and an invalid burst size. Looks like TX and RX burst both default to 16, per the Zynq manual. With the stream disable bit set, the behvior we see on our hardware is that priming just stops, with an outstanding transfer in memory marked active in the status field by the controller. This happens at random, even when doing single transfers at a time like with g_ether set to have a queue size of 1. With SDIS clear everything works great. Given that the Zynq is not bandwidth constrained, it seems like SDIS clear should be the default. I suspect the possible reason is the tx buffer for each endpoint is small (=512 bytes), so it can't copy one packet (assume max packet size for bulk) to tx buffer, then the prime can't be finished. Would you help to dump the registers HWTXBUF ($BASE + 0x10) and DCCPARAMS ($BASE + 124)? tx buffer size = ((2 ^ HWTXBUF.VUSB_HS_TX_ADD) / DCCPARAMS.DEN) * (DWORD_PER_BYTES) DWORD_PER_BYTES is 4 -- Best Regards, Peter Chen HWTXBUF is 0x80060A10, DCCPARAMS is 0xE0003124. Are you sure you read correct address? Your DCCPARAMS means it is host capable, but not device capable. HWTXBUF is 0x8060A10 DCCPARAMS is 0x018C VUSB_HS_TX_ADD - 0xA DEN - 0xC From the above formula tx buffer size is 341.33 bytes. Regards, Punnaiah -- Best Regards, Peter Chen -- 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 linux-kernel in the body of a message
Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
On Thu, Aug 27, 2015 at 3:45 PM, Jagan Teki wrote: > On 27 August 2015 at 14:18, punnaiah choudary kalluri > wrote: >> On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki wrote: >>> On 26 August 2015 at 21:02, punnaiah choudary kalluri >>> wrote: >>>> On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki wrote: >>>>> On 26 August 2015 at 11:56, Ranjit Waghmode >>>>> wrote: >>>>>> This series adds dual parallel mode support for Zynq Ultrascale+ >>>>>> MPSoC GQSPI controller driver. >>>>>> >>>>>> What is dual parallel mode? >>>>>> --- >>>>>> ZynqMP GQSPI controller supports Dual Parallel mode with following >>>>>> functionalities: >>>>>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. >>>>>> 2) Chip selects and clock are shared to both the flash devices >>>>>> 3) This mode is targeted for faster read/write speed and also doubles >>>>>> the size >>>>>> 4) Commands/data can be transmitted/received from both the >>>>>> devices(mirror), >>>>>>or only upper or only lower flash memory devices. >>>>>> 5) Data arrangement: >>>>>>With stripe enabled, >>>>>>Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus >>>>>>Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. >> >>>>> I don't find any previous discussion about way to inform flash >>>>> dual-ness into spi-nor >>>>> from spi drivers. >>>>> >>>>> Here is my idea, probably others may think same. >>>>> Informing dual_flash from drivers/spi through flags or any other mode >>>>> bits is not a better approach as dual flash feature is specific to >>>>> spi-nor flash controller (controller specially designed for spi-nor >>>>> flash not the generic spi controller). So if the driver sits on >>>>> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash >>>>> specific things to spi-nor as it's not touching generic spi stack in >>>>> Linux. But there is a defined-drawback if the driver is moved to >>>>> drivers/mtd/spi-nor ie it can't use spi core API's at-all. >>>> >>>> Xilinx GQSPI is a generic quad spi controller. The primary goal is to >>>> support >>>> Generic/Future command sequences and Future NOR/NAND flash devices. >>>> This core can also be used for legacy SPI devices. Due to the generic >>>> nature >>>> of the core, software can generate any command sequence. It also has >>>> additional >>>> features like parallel and stacked configurations to double the data >>>> rate and size. >>>> Accessing spi-nor flash device is one particular use case and like >>>> that there will be >>>> many. So, we decided to keep this driver in generic spi framework and >>>> that is the ideal >>>> thing to do for the GQSPI controller. >>> >>> Yes, I understand the generic nature of the GQSPI and it's good to >>> have all-in-one like generic spi, spi-nor and spi-nand and more >>> together, but Linux stacks were implemented in such a way to support >>> the each type of controller with connected slaves separably for better >>> handling. >> >> True and this is the reason we have controller drivers and protocol drivers. >> GQSPI is the controller driver and spi-nor and spi-nand are the >> protocol drivers. >> >>> >>> Currently GQSPI driver is added in drivers/spi as it supports generic >>> spi nature and now it enhanced more through flags for supporting >>> spi-nor, what if we add spi-nand support for the same controller? do >>> we add one more driver in spi-nand framework (drivers/mtd/spi-nand - >>> an on going implementation)? My only observation here is even if the >>> controller is more generic to support more number of device classes, >>> and adding same driver and populate the slave stuff through flags or >>> different kind of mechanism to different driver stack, this is not a >>> better approach I thought. >> >> Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific >> to flash parts, one can use for any other custom streaming protocols >> I would say exporting dual parallel connection to protocol drivers is >>
Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki wrote: > On 26 August 2015 at 21:02, punnaiah choudary kalluri > wrote: >> On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki wrote: >>> On 26 August 2015 at 11:56, Ranjit Waghmode >>> wrote: >>>> This series adds dual parallel mode support for Zynq Ultrascale+ >>>> MPSoC GQSPI controller driver. >>>> >>>> What is dual parallel mode? >>>> --- >>>> ZynqMP GQSPI controller supports Dual Parallel mode with following >>>> functionalities: >>>> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. >>>> 2) Chip selects and clock are shared to both the flash devices >>>> 3) This mode is targeted for faster read/write speed and also doubles the >>>> size >>>> 4) Commands/data can be transmitted/received from both the devices(mirror), >>>>or only upper or only lower flash memory devices. >>>> 5) Data arrangement: >>>>With stripe enabled, >>>>Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus >>>>Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. >>> I don't find any previous discussion about way to inform flash >>> dual-ness into spi-nor >>> from spi drivers. >>> >>> Here is my idea, probably others may think same. >>> Informing dual_flash from drivers/spi through flags or any other mode >>> bits is not a better approach as dual flash feature is specific to >>> spi-nor flash controller (controller specially designed for spi-nor >>> flash not the generic spi controller). So if the driver sits on >>> drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash >>> specific things to spi-nor as it's not touching generic spi stack in >>> Linux. But there is a defined-drawback if the driver is moved to >>> drivers/mtd/spi-nor ie it can't use spi core API's at-all. >> >> Xilinx GQSPI is a generic quad spi controller. The primary goal is to support >> Generic/Future command sequences and Future NOR/NAND flash devices. >> This core can also be used for legacy SPI devices. Due to the generic nature >> of the core, software can generate any command sequence. It also has >> additional >> features like parallel and stacked configurations to double the data >> rate and size. >> Accessing spi-nor flash device is one particular use case and like >> that there will be >> many. So, we decided to keep this driver in generic spi framework and >> that is the ideal >> thing to do for the GQSPI controller. > > Yes, I understand the generic nature of the GQSPI and it's good to > have all-in-one like generic spi, spi-nor and spi-nand and more > together, but Linux stacks were implemented in such a way to support > the each type of controller with connected slaves separably for better > handling. True and this is the reason we have controller drivers and protocol drivers. GQSPI is the controller driver and spi-nor and spi-nand are the protocol drivers. > > Currently GQSPI driver is added in drivers/spi as it supports generic > spi nature and now it enhanced more through flags for supporting > spi-nor, what if we add spi-nand support for the same controller? do > we add one more driver in spi-nand framework (drivers/mtd/spi-nand - > an on going implementation)? My only observation here is even if the > controller is more generic to support more number of device classes, > and adding same driver and populate the slave stuff through flags or > different kind of mechanism to different driver stack, this is not a > better approach I thought. Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific to flash parts, one can use for any other custom streaming protocols I would say exporting dual parallel connection to protocol drivers is something like depicting the spi bus topology to the protocol layer. AFAIK, spi-nor and spi-nand are protocol drivers for accessing the nor and nand flash devices sitting on the spi bus using the spi controller driver. Regards, Punnaiah > > Based on the above comments, there is an approach to handle this > support and I'm not 100% sure whether this fits or not but we > implemented the same - this is "probing child devices from parent" > (there was a discussion with Arnd earlier wrt this, but I'm unable to > get the mailing thread) > > Added Arnd (probably will give more inputs or corrections) > > Let me explain how we implemented on our design. > We have PCIe controller that support basic root complex handling, dma > and controller hotplug (not i
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
Hi, On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen wrote: > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: >> Hi, >> >> >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan >> wrote: >> > The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag, >> > unlike the default platform data. Add platform data specific to the >> > Zynq udc. >> > >> > Based on a patch by the same name from the Xilinx vendor tree. >> >> I am that Xilinx guy who sent this patch :). It is in Xilinx tree as >> temporary fix and >> I did not debug further why UDC works only when streaming is enabled. >> Probably this is right time to post my question here. >> I was expecting like: >> Streaming disabled - both low bandwidth and high bandwidth systems >> should work fine >> Streaming enabled - only for high bandwidth systems >> but this is not the case, Zynq UDC works only when Streaming is enabled. >> Please correct me if I am wrong. > > You are right, stream mode disabled should work at anytime. > It is so strange why zynq UDC only works when stream mode is enabled. I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc 2.20a, this is what it says about SDIS (streaming mode disable option) Before activating this mode, the user must check if the TX latency buffers per endpoint are able to accommodate at least one entire maximum size packet. The RX buffer size must, at least, double the TX buffer size per endpoint. To optimize the stream disable performance, system bus burst must be set as high as possible. When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a integer sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the controller will not work properly in stream disable mode. The stream disable mode should just be used in situations where the available system bandwidth is low or the system bus access latency is high, in order to avoid underruns and overruns in the latency buffers. This works for all types of endpoints, except for ISO endpoints. Such a system can't ensure the real time support that the ISO endpoints require, so the ISO endpoints are not supported when the SDIS bit is set. Definitely we need to root cause why disable streaming mode is not working for zynq but from controller spec point of view it is possible that controller not work properly in stream disable mode. Regards, Punnaiah > > Peter >> -- 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/
Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
On Thu, Aug 27, 2015 at 3:45 PM, Jagan Teki jt...@openedev.com wrote: On 27 August 2015 at 14:18, punnaiah choudary kalluri punn...@xilinx.com wrote: On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki jt...@openedev.com wrote: On 26 August 2015 at 21:02, punnaiah choudary kalluri punn...@xilinx.com wrote: On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki jt...@openedev.com wrote: On 26 August 2015 at 11:56, Ranjit Waghmode ranjit.waghm...@xilinx.com wrote: This series adds dual parallel mode support for Zynq Ultrascale+ MPSoC GQSPI controller driver. What is dual parallel mode? --- ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities: 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. 2) Chip selects and clock are shared to both the flash devices 3) This mode is targeted for faster read/write speed and also doubles the size 4) Commands/data can be transmitted/received from both the devices(mirror), or only upper or only lower flash memory devices. 5) Data arrangement: With stripe enabled, Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. snip I don't find any previous discussion about way to inform flash dual-ness into spi-nor from spi drivers. Here is my idea, probably others may think same. Informing dual_flash from drivers/spi through flags or any other mode bits is not a better approach as dual flash feature is specific to spi-nor flash controller (controller specially designed for spi-nor flash not the generic spi controller). So if the driver sits on drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash specific things to spi-nor as it's not touching generic spi stack in Linux. But there is a defined-drawback if the driver is moved to drivers/mtd/spi-nor ie it can't use spi core API's at-all. Xilinx GQSPI is a generic quad spi controller. The primary goal is to support Generic/Future command sequences and Future NOR/NAND flash devices. This core can also be used for legacy SPI devices. Due to the generic nature of the core, software can generate any command sequence. It also has additional features like parallel and stacked configurations to double the data rate and size. Accessing spi-nor flash device is one particular use case and like that there will be many. So, we decided to keep this driver in generic spi framework and that is the ideal thing to do for the GQSPI controller. Yes, I understand the generic nature of the GQSPI and it's good to have all-in-one like generic spi, spi-nor and spi-nand and more together, but Linux stacks were implemented in such a way to support the each type of controller with connected slaves separably for better handling. True and this is the reason we have controller drivers and protocol drivers. GQSPI is the controller driver and spi-nor and spi-nand are the protocol drivers. Currently GQSPI driver is added in drivers/spi as it supports generic spi nature and now it enhanced more through flags for supporting spi-nor, what if we add spi-nand support for the same controller? do we add one more driver in spi-nand framework (drivers/mtd/spi-nand - an on going implementation)? My only observation here is even if the controller is more generic to support more number of device classes, and adding same driver and populate the slave stuff through flags or different kind of mechanism to different driver stack, this is not a better approach I thought. Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific to flash parts, one can use for any other custom streaming protocols I would say exporting dual parallel connection to protocol drivers is something like depicting the spi bus topology to the protocol layer. So dual parallel may not used for spi-nor flash it can also used other spi slaves that's what your saying is it? Yes. As i said above, the main intention of this feature is to improve the data rate with an overhead of few IO lines. AFAIK, spi-nor and spi-nand are protocol drivers for accessing the nor and nand flash devices sitting on the spi bus using the spi controller driver. Yes, I do agree with your point, but though driver stacks are different with same kind of bus here, I'm trying to spit the GQSPI into 3 different controller drivers as Linux understand it and fit on to Linux stack with out disturbing the generic-ness. I feel this is not a nice idea. if there are 'n' functionalities and having 'n' controller drivers doesn't seem good in any direction. Protocol driver can query the spi core about the bus topology and it is the responsibility of the spi core and controller driver providing this information to the upper layers. Regards, Punnaiah Assumption is GQSPI shall split to various platform_drivers (if each platform driver treated as a controller) thought it made up
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
Hi, On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen peter.c...@freescale.com wrote: On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep subbaraya wrote: Hi, On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan nathan.sulli...@ni.com wrote: The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag, unlike the default platform data. Add platform data specific to the Zynq udc. Based on a patch by the same name from the Xilinx vendor tree. I am that Xilinx guy who sent this patch :). It is in Xilinx tree as temporary fix and I did not debug further why UDC works only when streaming is enabled. Probably this is right time to post my question here. I was expecting like: Streaming disabled - both low bandwidth and high bandwidth systems should work fine Streaming enabled - only for high bandwidth systems but this is not the case, Zynq UDC works only when Streaming is enabled. Please correct me if I am wrong. You are right, stream mode disabled should work at anytime. It is so strange why zynq UDC only works when stream mode is enabled. I am referring the section 8.5.2 in Synopsys usb 2.0 HS controllervDoc 2.20a, this is what it says about SDIS (streaming mode disable option) Before activating this mode, the user must check if the TX latency buffers per endpoint are able to accommodate at least one entire maximum size packet. The RX buffer size must, at least, double the TX buffer size per endpoint. To optimize the stream disable performance, system bus burst must be set as high as possible. When the stream disable mode is used, the burst size (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a integer sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If this is not respected the controller will not work properly in stream disable mode. The stream disable mode should just be used in situations where the available system bandwidth is low or the system bus access latency is high, in order to avoid underruns and overruns in the latency buffers. This works for all types of endpoints, except for ISO endpoints. Such a system can't ensure the real time support that the ISO endpoints require, so the ISO endpoints are not supported when the SDIS bit is set. Definitely we need to root cause why disable streaming mode is not working for zynq but from controller spec point of view it is possible that controller not work properly in stream disable mode. Regards, Punnaiah Peter -- 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/
Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
On Thu, Aug 27, 2015 at 11:53 AM, Jagan Teki jt...@openedev.com wrote: On 26 August 2015 at 21:02, punnaiah choudary kalluri punn...@xilinx.com wrote: On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki jt...@openedev.com wrote: On 26 August 2015 at 11:56, Ranjit Waghmode ranjit.waghm...@xilinx.com wrote: This series adds dual parallel mode support for Zynq Ultrascale+ MPSoC GQSPI controller driver. What is dual parallel mode? --- ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities: 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. 2) Chip selects and clock are shared to both the flash devices 3) This mode is targeted for faster read/write speed and also doubles the size 4) Commands/data can be transmitted/received from both the devices(mirror), or only upper or only lower flash memory devices. 5) Data arrangement: With stripe enabled, Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. snip I don't find any previous discussion about way to inform flash dual-ness into spi-nor from spi drivers. Here is my idea, probably others may think same. Informing dual_flash from drivers/spi through flags or any other mode bits is not a better approach as dual flash feature is specific to spi-nor flash controller (controller specially designed for spi-nor flash not the generic spi controller). So if the driver sits on drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash specific things to spi-nor as it's not touching generic spi stack in Linux. But there is a defined-drawback if the driver is moved to drivers/mtd/spi-nor ie it can't use spi core API's at-all. Xilinx GQSPI is a generic quad spi controller. The primary goal is to support Generic/Future command sequences and Future NOR/NAND flash devices. This core can also be used for legacy SPI devices. Due to the generic nature of the core, software can generate any command sequence. It also has additional features like parallel and stacked configurations to double the data rate and size. Accessing spi-nor flash device is one particular use case and like that there will be many. So, we decided to keep this driver in generic spi framework and that is the ideal thing to do for the GQSPI controller. Yes, I understand the generic nature of the GQSPI and it's good to have all-in-one like generic spi, spi-nor and spi-nand and more together, but Linux stacks were implemented in such a way to support the each type of controller with connected slaves separably for better handling. True and this is the reason we have controller drivers and protocol drivers. GQSPI is the controller driver and spi-nor and spi-nand are the protocol drivers. Currently GQSPI driver is added in drivers/spi as it supports generic spi nature and now it enhanced more through flags for supporting spi-nor, what if we add spi-nand support for the same controller? do we add one more driver in spi-nand framework (drivers/mtd/spi-nand - an on going implementation)? My only observation here is even if the controller is more generic to support more number of device classes, and adding same driver and populate the slave stuff through flags or different kind of mechanism to different driver stack, this is not a better approach I thought. Just to clear, dual parallel( 2 CS and 8 IO lines) is not only specific to flash parts, one can use for any other custom streaming protocols I would say exporting dual parallel connection to protocol drivers is something like depicting the spi bus topology to the protocol layer. AFAIK, spi-nor and spi-nand are protocol drivers for accessing the nor and nand flash devices sitting on the spi bus using the spi controller driver. Regards, Punnaiah Based on the above comments, there is an approach to handle this support and I'm not 100% sure whether this fits or not but we implemented the same - this is probing child devices from parent (there was a discussion with Arnd earlier wrt this, but I'm unable to get the mailing thread) Added Arnd (probably will give more inputs or corrections) Let me explain how we implemented on our design. We have PCIe controller that support basic root complex handling, dma and controller hotplug (not in-build pcie hp) and ideally we need to write driver for handling root complex on drivers/pci/host and one hotplug driver in drivers/pci and one more driver in drivers/dma for handling pcie dma stuff. And some pcie calls need to navigate from root complex driver to dma and hotplug driver that means there is call transition from driver/pci to driver/dma which is absolutely not a good approach (spi to spi-nor and spi-nand transition - in GQSPI case) So the implementation we follow is like there is a pcie root complex driver(probably generic spi driver in drivers/spi/*) and inside probe we have
Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki wrote: > On 26 August 2015 at 11:56, Ranjit Waghmode > wrote: >> This series adds dual parallel mode support for Zynq Ultrascale+ >> MPSoC GQSPI controller driver. >> >> What is dual parallel mode? >> --- >> ZynqMP GQSPI controller supports Dual Parallel mode with following >> functionalities: >> 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. >> 2) Chip selects and clock are shared to both the flash devices >> 3) This mode is targeted for faster read/write speed and also doubles the >> size >> 4) Commands/data can be transmitted/received from both the devices(mirror), >>or only upper or only lower flash memory devices. >> 5) Data arrangement: >>With stripe enabled, >>Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus >>Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. >> >> This series also updated MTD layer files for adding parallel mode support. >> >> 1) Added Support for two flashes >> 2) Support to enable/disable data stripe as and when required. >> 3) Added required parameters to spi_nor structure. Initialized all >>added parameters in spi_nor_scan() >> 4) Added support for dual parallel in spi_nor_read/write/erase functions by: >>a) Increasing page_size, sector_size, erase_size and toatal flash size >> as and when required. >>b) Dividing address by 2 >>c) Updating spi->master->flags for qspi driver to change CS >> 5) Updated read_sr() to get status of both flashes >> 6) Also updated read_fsr() to get status of both flashes >> >> These all are very high level changes and expected to make an idea clear. >> Comments and suggestions are always welcomed >> >> --- >> V2 Changes: >> a) Splitted patches based on logical changes >> b) Added error handling for newly added APIs in SPI core >> --- >> >> Ranjit Waghmode (4): >> spi: add support of two chip selects & data stripe >> mtd: add spi_device instance to spi_nor struct >> spi-nor: add dual parallel mode support >> spi: zynqmp: gqspi: add support for dual parallel mode configuration > > I don't find any previous discussion about way to inform flash > dual-ness into spi-nor > from spi drivers. > > Here is my idea, probably others may think same. > Informing dual_flash from drivers/spi through flags or any other mode > bits is not a better approach as dual flash feature is specific to > spi-nor flash controller (controller specially designed for spi-nor > flash not the generic spi controller). So if the driver sits on > drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash > specific things to spi-nor as it's not touching generic spi stack in > Linux. But there is a defined-drawback if the driver is moved to > drivers/mtd/spi-nor ie it can't use spi core API's at-all. Xilinx GQSPI is a generic quad spi controller. The primary goal is to support Generic/Future command sequences and Future NOR/NAND flash devices. This core can also be used for legacy SPI devices. Due to the generic nature of the core, software can generate any command sequence. It also has additional features like parallel and stacked configurations to double the data rate and size. Accessing spi-nor flash device is one particular use case and like that there will be many. So, we decided to keep this driver in generic spi framework and that is the ideal thing to do for the GQSPI controller. Regards, Punnaiah > > thanks! > -- > Jagan | openedev. > -- > 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 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/
Re: [LINUX RFC v2 0/4] spi: add dual parallel mode support in Zynq MPSoC GQSPI controller
On Wed, Aug 26, 2015 at 5:49 PM, Jagan Teki jt...@openedev.com wrote: On 26 August 2015 at 11:56, Ranjit Waghmode ranjit.waghm...@xilinx.com wrote: This series adds dual parallel mode support for Zynq Ultrascale+ MPSoC GQSPI controller driver. What is dual parallel mode? --- ZynqMP GQSPI controller supports Dual Parallel mode with following functionalities: 1) Supporting two SPI flash memories operating in parallel. 8 I/O lines. 2) Chip selects and clock are shared to both the flash devices 3) This mode is targeted for faster read/write speed and also doubles the size 4) Commands/data can be transmitted/received from both the devices(mirror), or only upper or only lower flash memory devices. 5) Data arrangement: With stripe enabled, Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. This series also updated MTD layer files for adding parallel mode support. 1) Added Support for two flashes 2) Support to enable/disable data stripe as and when required. 3) Added required parameters to spi_nor structure. Initialized all added parameters in spi_nor_scan() 4) Added support for dual parallel in spi_nor_read/write/erase functions by: a) Increasing page_size, sector_size, erase_size and toatal flash size as and when required. b) Dividing address by 2 c) Updating spi-master-flags for qspi driver to change CS 5) Updated read_sr() to get status of both flashes 6) Also updated read_fsr() to get status of both flashes These all are very high level changes and expected to make an idea clear. Comments and suggestions are always welcomed --- V2 Changes: a) Splitted patches based on logical changes b) Added error handling for newly added APIs in SPI core --- Ranjit Waghmode (4): spi: add support of two chip selects data stripe mtd: add spi_device instance to spi_nor struct spi-nor: add dual parallel mode support spi: zynqmp: gqspi: add support for dual parallel mode configuration I don't find any previous discussion about way to inform flash dual-ness into spi-nor from spi drivers. Here is my idea, probably others may think same. Informing dual_flash from drivers/spi through flags or any other mode bits is not a better approach as dual flash feature is specific to spi-nor flash controller (controller specially designed for spi-nor flash not the generic spi controller). So if the driver sits on drivers/mtd/spi-nor/ (ex: fsl-quadspi.c), may be we can inform flash specific things to spi-nor as it's not touching generic spi stack in Linux. But there is a defined-drawback if the driver is moved to drivers/mtd/spi-nor ie it can't use spi core API's at-all. Xilinx GQSPI is a generic quad spi controller. The primary goal is to support Generic/Future command sequences and Future NOR/NAND flash devices. This core can also be used for legacy SPI devices. Due to the generic nature of the core, software can generate any command sequence. It also has additional features like parallel and stacked configurations to double the data rate and size. Accessing spi-nor flash device is one particular use case and like that there will be many. So, we decided to keep this driver in generic spi framework and that is the ideal thing to do for the GQSPI controller. Regards, Punnaiah thanks! -- Jagan | openedev. -- 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 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/
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
Hi Rob,
On Tue, Aug 25, 2015 at 12:23 AM, Rob Herring wrote:
> On Wed, Aug 5, 2015 at 10:19 PM, Punnaiah Choudary Kalluri
> wrote:
>> Device-tree binding documentation for Xilinx zynqmp dma engine used in
>> Zynq UltraScale+ MPSoC.
>>
>> Signed-off-by: Punnaiah Choudary Kalluri
>> ---
>> Changes in v4:
>> - None
>> Changes in v3:
>> - None
>> Changes in v2:
>> - None
>> ---
>> .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61
>>
>> 1 files changed, 61 insertions(+), 0 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>> new file mode 100644
>> index 000..e4f92b9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
>> @@ -0,0 +1,61 @@
>> +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
>> +memory to device and device to memory transfers. It also has flow
>> +control and rate control support for slave/peripheral dma access.
>> +
>> +Required properties:
>> +- compatible: Should be "xlnx,zynqmp-dma-1.0"
>> +- #dma-cells: Should be <1>, a single cell holding a line request number
>> +- reg: Memory map for module access
>> +- interrupt-parent: Interrupt controller the interrupt is routed through
>> +- interrupts: Should contain DMA channel interrupt
>> +- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
>> +
>> +Optional properties:
>> +- xlnx,include-sg: Indicates the controller to operate in simple or scatter
>> + gather dma mode
>> +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
>> +source AXI transaction
>> +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the
>> data
>> +- xlnx,src-issue: Number of AXI outstanding transactions on source side
>> +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
>> + descriptor read are marked Non-coherent
>> +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
>> + source descriptor payload are marked Non-coherent
>> +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
>> + dst descriptor payload are marked Non-coherent
>
> Do you really need 3? dma-coherent property doesn't work for you?
>
> Not that it should dictate the binding, but the kernel doesn't support
> a device needing both coherent and non-coherent DMA ops.
I will get back to you shortly on this
>
>> +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
>> +- xlnx,src-axi-qos: AXI QOS bits to be used for data read
>> +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
>> +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
>> +- xlnx,desc-axi-cache: AXI cache bits to be used for data read
>> +- xlnx,desc-axi-cache: AXI cache bits to be used for data write
>
> These signals are generally part of the coherent or not setting. This
> allows for potentially invalid combinations.
>
> Plus you have a copy/paste error.
I will fix this.
Thanks,
Punnaiah
>
>> +- xlnx,src-burst-len: AXI length for data read. Support only power of 2
>> values
>> + i.e 1,2,4,8 and 16
>> +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2
>> values
>> + i.e 1,2,4,8 and 16
>> +
>> +Example:
>> +
>> +fpd_dma_chan1: dma@FD50 {
>> + compatible = "xlnx,zynqmp-dma-1.0";
>> + reg = <0x0 0xFD50 0x1000>;
>> + #dma_cells = <1>;
>> + interrupt-parent = <>;
>> + interrupts = <0 117 4>;
>> + xlnx,bus-width = <128>;
>> + xlnx,include-sg;
>> + xlnx,overfetch;
>> + xlnx,ratectrl = <0>;
>> + xlnx,src-issue = <16>;
>> + xlnx,desc-axi-cohrnt;
>> + xlnx,src-axi-cohrnt;
>> + xlnx,dst-axi-cohrnt;
>> + xlnx,desc-axi-qos = <0>;
>> + xlnx,desc-axi-cache = <0>;
>> + xlnx,src-axi-qos = <0>;
>> + xlnx,src-axi-cache = <2>;
>> + xlnx,dst-axi-qos = <0>;
>> + xlnx,dst-axi-cache = <2>;
>> + xlnx,src-burst-len = <4>;
>> + xlnx,dst-burst-len = <4>;
>> +};
>> --
>> 1.7.4
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
Hi Rob,
On Tue, Aug 25, 2015 at 12:23 AM, Rob Herring robherri...@gmail.com wrote:
On Wed, Aug 5, 2015 at 10:19 PM, Punnaiah Choudary Kalluri
punnaiah.choudary.kall...@xilinx.com wrote:
Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.
Signed-off-by: Punnaiah Choudary Kalluri punn...@xilinx.com
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..e4f92b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,61 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible: Should be xlnx,zynqmp-dma-1.0
+- #dma-cells: Should be 1, a single cell holding a line request number
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain DMA channel interrupt
+- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
+
+Optional properties:
+- xlnx,include-sg: Indicates the controller to operate in simple or scatter
+ gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
+source AXI transaction
+- xlnx,overfetch: Tells whether the channel is allowed to over fetch the
data
+- xlnx,src-issue: Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
+ descriptor read are marked Non-coherent
+- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
+ source descriptor payload are marked Non-coherent
+- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
+ dst descriptor payload are marked Non-coherent
Do you really need 3? dma-coherent property doesn't work for you?
Not that it should dictate the binding, but the kernel doesn't support
a device needing both coherent and non-coherent DMA ops.
I will get back to you shortly on this
+- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
+- xlnx,src-axi-qos: AXI QOS bits to be used for data read
+- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
+- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
+- xlnx,desc-axi-cache: AXI cache bits to be used for data read
+- xlnx,desc-axi-cache: AXI cache bits to be used for data write
These signals are generally part of the coherent or not setting. This
allows for potentially invalid combinations.
Plus you have a copy/paste error.
I will fix this.
Thanks,
Punnaiah
+- xlnx,src-burst-len: AXI length for data read. Support only power of 2
values
+ i.e 1,2,4,8 and 16
+- xlnx,dst-burst-len: AXI length for data write. Support only power of 2
values
+ i.e 1,2,4,8 and 16
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+ compatible = xlnx,zynqmp-dma-1.0;
+ reg = 0x0 0xFD50 0x1000;
+ #dma_cells = 1;
+ interrupt-parent = gic;
+ interrupts = 0 117 4;
+ xlnx,bus-width = 128;
+ xlnx,include-sg;
+ xlnx,overfetch;
+ xlnx,ratectrl = 0;
+ xlnx,src-issue = 16;
+ xlnx,desc-axi-cohrnt;
+ xlnx,src-axi-cohrnt;
+ xlnx,dst-axi-cohrnt;
+ xlnx,desc-axi-qos = 0;
+ xlnx,desc-axi-cache = 0;
+ xlnx,src-axi-qos = 0;
+ xlnx,src-axi-cache = 2;
+ xlnx,dst-axi-qos = 0;
+ xlnx,dst-axi-cache = 2;
+ xlnx,src-burst-len = 4;
+ xlnx,dst-burst-len = 4;
+};
--
1.7.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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/
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Mon, Aug 24, 2015 at 7:17 PM, Lars-Peter Clausen wrote: > On 08/06/2015 05:19 AM, Punnaiah Choudary Kalluri wrote: > [...] >> +Optional properties: >> +- xlnx,include-sg: Indicates the controller to operate in simple or scatter >> +gather dma mode >> +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for >> + source AXI transaction >> +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the >> data >> +- xlnx,src-issue: Number of AXI outstanding transactions on source side >> +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the >> + descriptor read are marked Non-coherent >> +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the >> + source descriptor payload are marked Non-coherent >> +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the >> + dst descriptor payload are marked Non-coherent >> +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch >> +- xlnx,src-axi-qos: AXI QOS bits to be used for data read >> +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write >> +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch. >> +- xlnx,desc-axi-cache: AXI cache bits to be used for data read >> +- xlnx,desc-axi-cache: AXI cache bits to be used for data write >> +- xlnx,src-burst-len: AXI length for data read. Support only power of 2 >> values >> + i.e 1,2,4,8 and 16 >> +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 >> values >> + i.e 1,2,4,8 and 16 > > None of these really belong into the devicetree. This is all runtime > configuration data. This is a general purpose dma and provides more flexibility to the user for configuring the descriptor, data and bus parameters. one way is as you said these parameters can be configured at runtime but i didn't find a way configuring the channel at runtime for mem to mem transfers. I have checked the device_config function description and it is strictly meant for slave operations only. So, i didn't see anything wrong having these parameter values from the device tree as these all are hw parameters. Regards, Punnaiah > > - Lars -- 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/
Re: [PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
On Mon, Aug 24, 2015 at 7:17 PM, Lars-Peter Clausen l...@metafoo.de wrote: On 08/06/2015 05:19 AM, Punnaiah Choudary Kalluri wrote: [...] +Optional properties: +- xlnx,include-sg: Indicates the controller to operate in simple or scatter +gather dma mode +- xlnx,ratectrl: Scheduling interval in terms of clock cycles for + source AXI transaction +- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data +- xlnx,src-issue: Number of AXI outstanding transactions on source side +- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the + descriptor read are marked Non-coherent +- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the + source descriptor payload are marked Non-coherent +- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the + dst descriptor payload are marked Non-coherent +- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch +- xlnx,src-axi-qos: AXI QOS bits to be used for data read +- xlnx,dst-axi-qos: AXI QOS bits to be used for data write +- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch. +- xlnx,desc-axi-cache: AXI cache bits to be used for data read +- xlnx,desc-axi-cache: AXI cache bits to be used for data write +- xlnx,src-burst-len: AXI length for data read. Support only power of 2 values + i.e 1,2,4,8 and 16 +- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 values + i.e 1,2,4,8 and 16 None of these really belong into the devicetree. This is all runtime configuration data. This is a general purpose dma and provides more flexibility to the user for configuring the descriptor, data and bus parameters. one way is as you said these parameters can be configured at runtime but i didn't find a way configuring the channel at runtime for mem to mem transfers. I have checked the device_config function description and it is strictly meant for slave operations only. So, i didn't see anything wrong having these parameter values from the device tree as these all are hw parameters. Regards, Punnaiah - Lars -- 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/
Re: [PATCH v4 2/2] dma: Add Xilinx zynqmp dma engine driver support
On Sun, Aug 23, 2015 at 7:38 PM, Vinod Koul wrote:
> On Thu, Aug 20, 2015 at 12:01:27PM +0530, punnaiah choudary kalluri wrote:
>> On Thu, Aug 20, 2015 at 11:43 AM, Vinod Koul wrote:
>> > On Thu, Aug 06, 2015 at 08:49:33AM +0530, Punnaiah Choudary Kalluri wrote:
>> >
>> >> + list_for_each_entry_safe(desc, next, >done_list, node) {
>> >> + dma_async_tx_callback callback;
>> >> + void *callback_param;
>> >> +
>> >> + list_del(>node);
>> >> +
>> >> + callback = desc->async_tx.callback;
>> >> + callback_param = desc->async_tx.callback_param;
>> >> + if (callback) {
>> >> + if (in_interrupt())
>> >> + spin_unlock_bh(>lock);
>> >> + else
>> >> + spin_unlock(>lock);
>> >
>> > This looks bad!
>> > Why would callback be called from different context. It should only be
>> > invoked from your tasklet
>>
>> During the terminate call, driver need to clean up the existing BDs so that
>> time
>> this function will be called from the thread or process context in
>> addition to the
>> tasklet context.
>>
>> DO you have any suggestion here ?
>
> Yes you need to terminate but you don't need to invoke user for terminate
> flow. It is not expected.
> Terminate flow expect youu to clean the channels
Ok. Thanks. I will fix this and send v5 soon.
Regards,
Punnaiah
>
> --
> ~Vinod
> --
> 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 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/
Re: [PATCH v4 2/2] dma: Add Xilinx zynqmp dma engine driver support
On Sun, Aug 23, 2015 at 7:38 PM, Vinod Koul vinod.k...@intel.com wrote:
On Thu, Aug 20, 2015 at 12:01:27PM +0530, punnaiah choudary kalluri wrote:
On Thu, Aug 20, 2015 at 11:43 AM, Vinod Koul vinod.k...@intel.com wrote:
On Thu, Aug 06, 2015 at 08:49:33AM +0530, Punnaiah Choudary Kalluri wrote:
+ list_for_each_entry_safe(desc, next, chan-done_list, node) {
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ list_del(desc-node);
+
+ callback = desc-async_tx.callback;
+ callback_param = desc-async_tx.callback_param;
+ if (callback) {
+ if (in_interrupt())
+ spin_unlock_bh(chan-lock);
+ else
+ spin_unlock(chan-lock);
This looks bad!
Why would callback be called from different context. It should only be
invoked from your tasklet
During the terminate call, driver need to clean up the existing BDs so that
time
this function will be called from the thread or process context in
addition to the
tasklet context.
DO you have any suggestion here ?
Yes you need to terminate but you don't need to invoke user for terminate
flow. It is not expected.
Terminate flow expect youu to clean the channels
Ok. Thanks. I will fix this and send v5 soon.
Regards,
Punnaiah
--
~Vinod
--
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 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/
