From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vignesh Raghavendra <vigneshr@ti.com>
Cc: tudor.ambarus@microchip.com, juliensu@mxic.com.tw,
richard@nod.at, linux-kernel@vger.kernel.org,
linux-spi@vger.kernel.org, broonie@kernel.org,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
Mason Yang <masonccyang@mxic.com.tw>,
Pratyush Yadav <p.yadav@ti.com>
Subject: Re: [PATCH v2 0/5] mtd: spi-nor: Add support for Octal 8D-8D-8D mode
Date: Tue, 21 Apr 2020 14:17:25 +0200 [thread overview]
Message-ID: <20200421141725.24ce5986@collabora.com> (raw)
In-Reply-To: <56365995-fe30-534f-9dbc-7307d9b9f846@ti.com>
On Tue, 21 Apr 2020 15:05:08 +0530
Vignesh Raghavendra <vigneshr@ti.com> wrote:
> On 21/04/20 12:53 pm, Boris Brezillon wrote:
> > +Pratyush who's working on a similar patchet [1].
> >
> > Hello Mason,
> >
> > On Tue, 21 Apr 2020 14:39:42 +0800
> > Mason Yang <masonccyang@mxic.com.tw> wrote:
> >
> >> Hello,
> >>
> >> This is repost of patchset from Boris Brezillon's
> >> [RFC,00/18] mtd: spi-nor: Proposal for 8-8-8 mode support [1].
> >
> > I only quickly went through the patches you sent and saying it's a
> > repost of the RFC is a bit of a lie. You completely ignored the state
> > tracking I was trying to do to avoid leaving the flash in 8D mode when
> > suspending/resetting the board, and I think that part is crucial. If I
> > remember correctly, we already had this discussion so I must say I'm a
> > bit disappointed.
> >
> > Can you sync with Pratyush? I think his series [1] is better in that it
> > tries to restore the flash in single-SPI mode before suspend (it's
> > missing the shutdown case, but that can be easily added I think). Of
> > course that'd be even better to have proper state tracking at the SPI
> > NOR level.
> >
>
> [1] does soft reset on shutdown which should put it to reset default
> state of 1S-1S-1S mode (if thats the POR default)
Oh ok, looks like I didn't read the patch series carefully enough.
>
> But, there is still one open question now that we are considering
> supporting stateful modes:
>
> What to do with flashes that power up in 8D mode either due to factory
> defaults or if 8D mode NV bit is set? Do we say SPI NOR framework won't
> support such flashes?
> Auto discovery of such flashes is quite difficult as different flashes
> use different protocols for RDID cmd in 8D mode (address phase may or
> may not be present, dummy cycles vary etc) is almost impossible w/o any
> hint passed to the driver?
I don't know yet. Looks like we'll have to pass the part-id and default
mode for those flashes (part-name being a part-specific compatible, and
boot-up mode being an extra property). But maybe we can ignore that for
now and focus on flashes booting in single SPI mode first :P.
______________________________________________________
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: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Mason Yang <masonccyang@mxic.com.tw>, <broonie@kernel.org>,
<tudor.ambarus@microchip.com>, <miquel.raynal@bootlin.com>,
<richard@nod.at>, <juliensu@mxic.com.tw>,
<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
<linux-spi@vger.kernel.org>, Pratyush Yadav <p.yadav@ti.com>
Subject: Re: [PATCH v2 0/5] mtd: spi-nor: Add support for Octal 8D-8D-8D mode
Date: Tue, 21 Apr 2020 14:17:25 +0200 [thread overview]
Message-ID: <20200421141725.24ce5986@collabora.com> (raw)
In-Reply-To: <56365995-fe30-534f-9dbc-7307d9b9f846@ti.com>
On Tue, 21 Apr 2020 15:05:08 +0530
Vignesh Raghavendra <vigneshr@ti.com> wrote:
> On 21/04/20 12:53 pm, Boris Brezillon wrote:
> > +Pratyush who's working on a similar patchet [1].
> >
> > Hello Mason,
> >
> > On Tue, 21 Apr 2020 14:39:42 +0800
> > Mason Yang <masonccyang@mxic.com.tw> wrote:
> >
> >> Hello,
> >>
> >> This is repost of patchset from Boris Brezillon's
> >> [RFC,00/18] mtd: spi-nor: Proposal for 8-8-8 mode support [1].
> >
> > I only quickly went through the patches you sent and saying it's a
> > repost of the RFC is a bit of a lie. You completely ignored the state
> > tracking I was trying to do to avoid leaving the flash in 8D mode when
> > suspending/resetting the board, and I think that part is crucial. If I
> > remember correctly, we already had this discussion so I must say I'm a
> > bit disappointed.
> >
> > Can you sync with Pratyush? I think his series [1] is better in that it
> > tries to restore the flash in single-SPI mode before suspend (it's
> > missing the shutdown case, but that can be easily added I think). Of
> > course that'd be even better to have proper state tracking at the SPI
> > NOR level.
> >
>
> [1] does soft reset on shutdown which should put it to reset default
> state of 1S-1S-1S mode (if thats the POR default)
Oh ok, looks like I didn't read the patch series carefully enough.
>
> But, there is still one open question now that we are considering
> supporting stateful modes:
>
> What to do with flashes that power up in 8D mode either due to factory
> defaults or if 8D mode NV bit is set? Do we say SPI NOR framework won't
> support such flashes?
> Auto discovery of such flashes is quite difficult as different flashes
> use different protocols for RDID cmd in 8D mode (address phase may or
> may not be present, dummy cycles vary etc) is almost impossible w/o any
> hint passed to the driver?
I don't know yet. Looks like we'll have to pass the part-id and default
mode for those flashes (part-name being a part-specific compatible, and
boot-up mode being an extra property). But maybe we can ignore that for
now and focus on flashes booting in single SPI mode first :P.
next prev parent reply other threads:[~2020-04-21 12:17 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-21 6:39 [PATCH v2 0/5] mtd: spi-nor: Add support for Octal 8D-8D-8D mode Mason Yang
2020-04-21 6:39 ` Mason Yang
2020-04-21 6:39 ` [PATCH v2 1/5] " Mason Yang
2020-04-21 6:39 ` Mason Yang
2020-04-21 6:39 ` [PATCH v2 2/5] mtd: spi-nor: sfdp: Add support for xSPI profile 1.0 table Mason Yang
2020-04-21 6:39 ` Mason Yang
2020-04-21 6:39 ` [PATCH v2 3/5] mtd: spi-nor: Parse BFPT DWORD-18, 19 and 20 for Octal 8D-8D-8D mode Mason Yang
2020-04-21 6:39 ` [PATCH v2 3/5] mtd: spi-nor: Parse BFPT DWORD-18,19 " Mason Yang
2020-04-21 6:39 ` [PATCH v2 4/5] mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports for Macronix mx25uw51245g Mason Yang
2020-04-21 6:39 ` Mason Yang
2020-04-21 6:39 ` [PATCH v2 5/5] spi: mxic: Patch for Octal 8D-8D-8D mode support Mason Yang
2020-04-21 6:39 ` Mason Yang
2020-04-24 15:41 ` kbuild test robot
2020-04-24 15:41 ` kbuild test robot
2020-04-24 15:41 ` kbuild test robot
2020-04-21 7:23 ` [PATCH v2 0/5] mtd: spi-nor: Add support for Octal 8D-8D-8D mode Boris Brezillon
2020-04-21 7:23 ` Boris Brezillon
2020-04-21 9:35 ` Vignesh Raghavendra
2020-04-21 9:35 ` Vignesh Raghavendra
2020-04-21 12:17 ` Boris Brezillon [this message]
2020-04-21 12:17 ` Boris Brezillon
2020-04-27 17:55 ` Pratyush Yadav
2020-04-27 17:55 ` Pratyush Yadav
2020-04-28 6:14 ` masonccyang
2020-04-28 6:14 ` masonccyang
2020-04-28 6:34 ` Boris Brezillon
2020-04-28 6:34 ` Boris Brezillon
2020-04-28 8:35 ` Pratyush Yadav
2020-04-28 8:35 ` Pratyush Yadav
2020-04-29 5:59 ` masonccyang
2020-04-29 5:59 ` masonccyang
2020-04-28 8:54 ` Pratyush Yadav
2020-04-28 8:54 ` Pratyush Yadav
2020-04-29 7:31 ` masonccyang
2020-04-29 7:31 ` masonccyang
2020-04-29 8:37 ` Boris Brezillon
2020-04-29 8:37 ` Boris Brezillon
2020-04-29 18:18 ` Pratyush Yadav
2020-04-29 18:18 ` Pratyush Yadav
2020-05-05 9:31 ` masonccyang
2020-05-05 9:31 ` masonccyang
2020-05-05 9:44 ` Boris Brezillon
2020-05-05 9:44 ` Boris Brezillon
2020-05-05 10:01 ` Boris Brezillon
2020-05-05 10:01 ` Boris Brezillon
2020-05-11 6:54 ` masonccyang
2020-05-11 6:54 ` masonccyang
2020-05-06 9:40 ` Pratyush Yadav
2020-05-06 9:40 ` Pratyush Yadav
2020-05-15 2:26 ` masonccyang
2020-05-15 2:26 ` masonccyang
2020-05-15 6:55 ` Pratyush Yadav
2020-05-15 6:55 ` Pratyush Yadav
2020-04-30 8:21 ` Vignesh Raghavendra
2020-04-30 8:21 ` Vignesh Raghavendra
2020-05-11 3:23 ` masonccyang
2020-05-11 3:23 ` masonccyang
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=20200421141725.24ce5986@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=broonie@kernel.org \
--cc=juliensu@mxic.com.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=masonccyang@mxic.com.tw \
--cc=miquel.raynal@bootlin.com \
--cc=p.yadav@ti.com \
--cc=richard@nod.at \
--cc=tudor.ambarus@microchip.com \
--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.