All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Md Sadre Alam <mdalam@codeaurora.org>
Cc: agross@kernel.org, bjorn.andersson@linaro.org,
	miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
	robh+dt@kernel.org, linux-arm-msm@vger.kernel.org,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, sricharan@codeaurora.org
Subject: Re: [PATCH 2/5] mtd: rawnand: qcom: Add initial support for qspi nand
Date: Thu, 29 Oct 2020 10:07:51 +0100	[thread overview]
Message-ID: <20201029100751.713e27df@collabora.com> (raw)
In-Reply-To: <1602307902-16761-3-git-send-email-mdalam@codeaurora.org>

Hello,

On Sat, 10 Oct 2020 11:01:39 +0530
Md Sadre Alam <mdalam@codeaurora.org> wrote:

> This change will add initial support for qspi (serial nand).
> 
> QPIC Version v.2.0 onwards supports serial nand as well so this
> change will initialize all required register to enable qspi (serial
> nand).
> 
> This change is supporting very basic functionality of qspi nand flash.
> 
> 1. Reset device (Reset QSPI NAND device).
> 
> 2. Device detection (Read id QSPI NAND device).

Unfortunately, that's not going to work in the long term. You're
basically hacking the raw NAND framework to make SPI NANDs fit. I do
understand the rationale behind this decision (re-using the code for
ECC and probably other things), but that's not going to work. So I'd
recommend doing the following instead:

1/ implement a SPI-mem controller driver
2/ implement an ECC engine driver so the ECC logic can be shared
   between the SPI controller and raw NAND controller drivers
3/ convert the raw NAND driver to the exec_op() interface (none of
   this hack would have been possible if the driver was using the new
   API)

Regards,

Boris

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Md Sadre Alam <mdalam@codeaurora.org>
Cc: devicetree@vger.kernel.org, vigneshr@ti.com, richard@nod.at,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	robh+dt@kernel.org, bjorn.andersson@linaro.org,
	agross@kernel.org, linux-mtd@lists.infradead.org,
	miquel.raynal@bootlin.com, sricharan@codeaurora.org
Subject: Re: [PATCH 2/5] mtd: rawnand: qcom: Add initial support for qspi nand
Date: Thu, 29 Oct 2020 10:07:51 +0100	[thread overview]
Message-ID: <20201029100751.713e27df@collabora.com> (raw)
In-Reply-To: <1602307902-16761-3-git-send-email-mdalam@codeaurora.org>

Hello,

On Sat, 10 Oct 2020 11:01:39 +0530
Md Sadre Alam <mdalam@codeaurora.org> wrote:

> This change will add initial support for qspi (serial nand).
> 
> QPIC Version v.2.0 onwards supports serial nand as well so this
> change will initialize all required register to enable qspi (serial
> nand).
> 
> This change is supporting very basic functionality of qspi nand flash.
> 
> 1. Reset device (Reset QSPI NAND device).
> 
> 2. Device detection (Read id QSPI NAND device).

Unfortunately, that's not going to work in the long term. You're
basically hacking the raw NAND framework to make SPI NANDs fit. I do
understand the rationale behind this decision (re-using the code for
ECC and probably other things), but that's not going to work. So I'd
recommend doing the following instead:

1/ implement a SPI-mem controller driver
2/ implement an ECC engine driver so the ECC logic can be shared
   between the SPI controller and raw NAND controller drivers
3/ convert the raw NAND driver to the exec_op() interface (none of
   this hack would have been possible if the driver was using the new
   API)

Regards,

Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-10-29  9:07 UTC|newest]

Thread overview: 39+ 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 [this message]
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
2020-10-29  8:38         ` Boris Brezillon
  -- strict thread matches above, loose matches on Subject: below --
2020-11-27 14:47 [PATCH 2/5] mtd: rawnand: qcom: Add initial support for qspi nand mdalam

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=20201029100751.713e27df@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.