From: Boris Brezillon <boris.brezillon@collabora.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: mdalam@codeaurora.org, devicetree@vger.kernel.org,
vigneshr@ti.com, richard@nod.at, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, bjorn.andersson@linaro.org,
agross@kernel.org, linux-mtd@lists.infradead.org,
linux-arm-msm@vger.kernel.org, sricharan@codeaurora.org
Subject: Re: [PATCH 0/5] mtd: rawnand: qcom: Add support for QSPI nand
Date: Thu, 29 Oct 2020 09:38:16 +0100 [thread overview]
Message-ID: <20201029093816.7dab154a@collabora.com> (raw)
In-Reply-To: <20201029085344.5b2a4b51@xps13>
On Thu, 29 Oct 2020 08:53:44 +0100
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Hello,
>
> mdalam@codeaurora.org wrote on Wed, 28 Oct 2020 23:54:23 +0530:
>
> > On 2020-10-28 15:18, Miquel Raynal wrote:
> > > Hello,
> > >
> > > Md Sadre Alam <mdalam@codeaurora.org> wrote on Sat, 10 Oct 2020
> > > 11:01:37 +0530:
> > >
> > >> QPIC 2.0 supports Serial NAND support in addition to all features and
> > >> commands in QPIC 1.0 for parallel NAND. Parallel and Serial NAND >> cannot
> > >> operate simultaneously. QSPI nand devices will connect to QPIC >> IO_MACRO
> > >> block of QPIC controller. There is a separate IO_MACRO clock for >> IO_MACRO
> > >> block. Default IO_MACRO block divide the input clock by 4. so if >> IO_MACRO
> > >> input clock is 320MHz then on bus it will be 80MHz, so QSPI nand >> device
> > >> should also support this frequency.
> > >> >> QPIC provides 4 data pins to QSPI nand. In standard SPI mode (x1 mode) >> data
> > >> transfer will occur on only 2 pins one pin for Serial data in and one >> for
> > >> serial data out. In QUAD SPI mode (x4 mode) data transfer will occur >> at all
> > >> the four data lines. QPIC controller supports command for x1 mode and >> x4 mode.
> > >> >> Md Sadre Alam (5):
> > >> dt-bindings: qcom_nandc: IPQ5018 QPIC NAND documentation
> > >> mtd: rawnand: qcom: Add initial support for qspi nand
> > >> mtd: rawnand: qcom: Read QPIC version
> > >> mtd: rawnand: qcom: Enable support for erase,read & write for serial
> > >> nand.
> > >> mtd: rawnand: qcom: Add support for serial training.
> > >> >> .../devicetree/bindings/mtd/qcom_nandc.txt | 3 +
> > >> drivers/mtd/nand/raw/nand_ids.c | 13 +
> > >> drivers/mtd/nand/raw/qcom_nandc.c | 502 >> ++++++++++++++++++++-
> > >> 3 files changed, 494 insertions(+), 24 deletions(-)
> > >> > > I'm sorry but this series clearly breaks the current layering. I cannot
> > > authorize SPI-NAND code to fall into the raw NAND subsystem.
> > >
> >
> > I am agree with you, we should not add SPI-NAND changes inside
> > raw NAND subsystem.
> >
> > > As both typologies cannot be used at the same time, I guess you should
> > > have another driver handling this feature under the spi/ subsystem +
> > > a few declarations in the SPI-NAND devices list.
> > >
> >
> > Initially I was started writing separate driver under SPI-NAND subsystem then I
> > realized that more than 85% of raw/qcom_nand.c code getting duplicated.
> >
> > That's why I have added this SPI-NAND change in raw/qcom_nand.c since
> > more than 85% of code will be reused.
> >
> > If I will add this change inside SPI-NAND subsystem then much of
> > raw/qcom_nand.c code will get duplicated. Would it be ok ?
>
> What about moving the generic code to drivers/mtd/nand/common/ and
Yeah, I don't think drivers/mtd/nand/common/ is the right place to put
this common code TBH, and I don't really see what's to be shared between
the NAND controller and SPI controller drivers. If it's just helpers to
access the registers, those can probably live in
drivers/soc/qcom/qcom_qpic2.c.
> referring to it from drivers/mtd/nand/raw/qcom_nand.c and
> drivers/spi/spi-qcom.c (or such)?
>
> Thanks,
> Miquèl
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: mdalam@codeaurora.org, devicetree@vger.kernel.org,
vigneshr@ti.com, richard@nod.at, linux-kernel@vger.kernel.org,
bjorn.andersson@linaro.org, robh+dt@kernel.org,
linux-mtd@lists.infradead.org, agross@kernel.org,
linux-arm-msm@vger.kernel.org, sricharan@codeaurora.org
Subject: Re: [PATCH 0/5] mtd: rawnand: qcom: Add support for QSPI nand
Date: Thu, 29 Oct 2020 09:38:16 +0100 [thread overview]
Message-ID: <20201029093816.7dab154a@collabora.com> (raw)
In-Reply-To: <20201029085344.5b2a4b51@xps13>
On Thu, 29 Oct 2020 08:53:44 +0100
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Hello,
>
> mdalam@codeaurora.org wrote on Wed, 28 Oct 2020 23:54:23 +0530:
>
> > On 2020-10-28 15:18, Miquel Raynal wrote:
> > > Hello,
> > >
> > > Md Sadre Alam <mdalam@codeaurora.org> wrote on Sat, 10 Oct 2020
> > > 11:01:37 +0530:
> > >
> > >> QPIC 2.0 supports Serial NAND support in addition to all features and
> > >> commands in QPIC 1.0 for parallel NAND. Parallel and Serial NAND >> cannot
> > >> operate simultaneously. QSPI nand devices will connect to QPIC >> IO_MACRO
> > >> block of QPIC controller. There is a separate IO_MACRO clock for >> IO_MACRO
> > >> block. Default IO_MACRO block divide the input clock by 4. so if >> IO_MACRO
> > >> input clock is 320MHz then on bus it will be 80MHz, so QSPI nand >> device
> > >> should also support this frequency.
> > >> >> QPIC provides 4 data pins to QSPI nand. In standard SPI mode (x1 mode) >> data
> > >> transfer will occur on only 2 pins one pin for Serial data in and one >> for
> > >> serial data out. In QUAD SPI mode (x4 mode) data transfer will occur >> at all
> > >> the four data lines. QPIC controller supports command for x1 mode and >> x4 mode.
> > >> >> Md Sadre Alam (5):
> > >> dt-bindings: qcom_nandc: IPQ5018 QPIC NAND documentation
> > >> mtd: rawnand: qcom: Add initial support for qspi nand
> > >> mtd: rawnand: qcom: Read QPIC version
> > >> mtd: rawnand: qcom: Enable support for erase,read & write for serial
> > >> nand.
> > >> mtd: rawnand: qcom: Add support for serial training.
> > >> >> .../devicetree/bindings/mtd/qcom_nandc.txt | 3 +
> > >> drivers/mtd/nand/raw/nand_ids.c | 13 +
> > >> drivers/mtd/nand/raw/qcom_nandc.c | 502 >> ++++++++++++++++++++-
> > >> 3 files changed, 494 insertions(+), 24 deletions(-)
> > >> > > I'm sorry but this series clearly breaks the current layering. I cannot
> > > authorize SPI-NAND code to fall into the raw NAND subsystem.
> > >
> >
> > I am agree with you, we should not add SPI-NAND changes inside
> > raw NAND subsystem.
> >
> > > As both typologies cannot be used at the same time, I guess you should
> > > have another driver handling this feature under the spi/ subsystem +
> > > a few declarations in the SPI-NAND devices list.
> > >
> >
> > Initially I was started writing separate driver under SPI-NAND subsystem then I
> > realized that more than 85% of raw/qcom_nand.c code getting duplicated.
> >
> > That's why I have added this SPI-NAND change in raw/qcom_nand.c since
> > more than 85% of code will be reused.
> >
> > If I will add this change inside SPI-NAND subsystem then much of
> > raw/qcom_nand.c code will get duplicated. Would it be ok ?
>
> What about moving the generic code to drivers/mtd/nand/common/ and
Yeah, I don't think drivers/mtd/nand/common/ is the right place to put
this common code TBH, and I don't really see what's to be shared between
the NAND controller and SPI controller drivers. If it's just helpers to
access the registers, those can probably live in
drivers/soc/qcom/qcom_qpic2.c.
> referring to it from drivers/mtd/nand/raw/qcom_nand.c and
> drivers/spi/spi-qcom.c (or such)?
>
> Thanks,
> Miquèl
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-10-29 8:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-10 5:31 [PATCH 0/5] mtd: rawnand: qcom: Add support for QSPI nand Md Sadre Alam
2020-10-10 5:31 ` Md Sadre Alam
2020-10-10 5:31 ` [PATCH 1/5] dt-bindings: qcom_nandc: IPQ5018 QPIC NAND documentation Md Sadre Alam
2020-10-10 5:31 ` Md Sadre Alam
2020-10-13 16:21 ` Rob Herring
2020-10-13 16:21 ` Rob Herring
2020-10-10 5:31 ` [PATCH 2/5] mtd: rawnand: qcom: Add initial support for qspi nand Md Sadre Alam
2020-10-10 5:31 ` Md Sadre Alam
2020-10-29 9:07 ` Boris Brezillon
2020-10-29 9:07 ` Boris Brezillon
2023-03-06 14:15 ` Md Sadre Alam
2023-03-06 14:15 ` Md Sadre Alam
2023-03-06 14:33 ` Md Sadre Alam
2023-03-06 14:33 ` Md Sadre Alam
2023-03-06 14:38 ` Miquel Raynal
2023-03-06 14:38 ` Miquel Raynal
2023-03-27 13:54 ` Md Sadre Alam
2023-03-27 13:54 ` Md Sadre Alam
2023-03-27 14:49 ` Miquel Raynal
2023-03-27 14:49 ` Miquel Raynal
2023-03-28 11:18 ` Md Sadre Alam
2023-03-28 11:18 ` Md Sadre Alam
2020-10-10 5:31 ` [PATCH 3/5] mtd: rawnand: qcom: Read QPIC version Md Sadre Alam
2020-10-10 5:31 ` Md Sadre Alam
2020-10-10 5:31 ` [PATCH 4/5] mtd: rawnand: qcom: Enable support for erase,read & write for serial nand Md Sadre Alam
2020-10-10 5:31 ` [PATCH 4/5] mtd: rawnand: qcom: Enable support for erase, read " Md Sadre Alam
2020-10-10 5:31 ` [PATCH 5/5] mtd: rawnand: qcom: Add support for serial training Md Sadre Alam
2020-10-10 5:31 ` Md Sadre Alam
2020-10-28 9:48 ` [PATCH 0/5] mtd: rawnand: qcom: Add support for QSPI nand Miquel Raynal
2020-10-28 9:48 ` Miquel Raynal
2020-10-28 18:24 ` mdalam
2020-10-28 18:24 ` mdalam
2020-10-29 7:53 ` Miquel Raynal
2020-10-29 7:53 ` Miquel Raynal
2020-10-29 8:37 ` Miquel Raynal
2020-10-29 8:37 ` Miquel Raynal
2020-10-29 8:38 ` Boris Brezillon [this message]
2020-10-29 8:38 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201029093816.7dab154a@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mdalam@codeaurora.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=sricharan@codeaurora.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.