From: Marek Vasut <marex@denx.de>
To: Kevin Cernekee <cernekee@gmail.com>
Cc: David Woodhouse <david.woodhouse@intel.com>,
dedekind1@gmail.com,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
devicetree-discuss@lists.ozlabs.org, robherring2@gmail.com,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH V5] mtd: m25p80: Make fast read configurable via DT
Date: Sat, 25 Aug 2012 22:40:54 +0200 [thread overview]
Message-ID: <201208252240.54932.marex@denx.de> (raw)
In-Reply-To: <CAJiQ=7BAH_87jrDCG=Jbw7ezsezFWrBv+eUkoH5jGmeV9tQiYQ@mail.gmail.com>
Dear Kevin Cernekee,
> On Sat, Aug 25, 2012 at 12:36 PM, Marek Vasut <marex@denx.de> wrote:
> > Add DT property "m25p,fast-read" that signalises the particular
> > chip supports "fast read" opcode.
>
> This might be slightly clearer if it is rephrased as:
>
> Add DT property "m25p,fast-read" that signifies whether the "fast
> read" opcode is supported.
What's the difference?
> > +Optional properties:
> > +- m25p,fast-read : Use the "fast read" opcode to read data from the chip
> > instead + of the usual "read" opcode. This opcode isn
> > not supported by + all chips and support for it can
> > not be detected at runtime.
>
> "is not supported"
Thanks
> Are there any modern SPI flash parts that can't handle FAST_READ, or
> is this mostly for compatibility with legacy systems?
We have to support all possibilities, not only "modern systems" .
> > + bool fast_read;
> >
> > - t[0].len = m25p_cmdsz(flash) + FAST_READ_DUMMY_BYTE;
> > + t[0].len = m25p_cmdsz(flash) + (flash->fast_read ? 1 : 0);
>
> Newer devices support a variable number of dummy cycles; increasing
> the number of dummy cycles can allow for higher interface speeds. One
> example is the Macronix MX25L25635F:
>
> http://bit.ly/P9s7UM
Good, but I don't see it supported in the driver, how is this different from
MX25L256E?
Besides, I noticed the fast-read isn't even properly excersized, as it always
reads blocks of 512 bytes, even if it can read any basically length. Why is
that, MTD layer stuff or something?
> It might be worth thinking about how to capture this sort of
> information in the DT properties, even if current versions of m25p80
> only use a small subset of the device capabilities.
They can be added as additional DT props, that should be easy.
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Kevin Cernekee <cernekee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: David Woodhouse
<david.woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Artem Bityutskiy
<artem.bityutskiy-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH V5] mtd: m25p80: Make fast read configurable via DT
Date: Sat, 25 Aug 2012 22:40:54 +0200 [thread overview]
Message-ID: <201208252240.54932.marex@denx.de> (raw)
In-Reply-To: <CAJiQ=7BAH_87jrDCG=Jbw7ezsezFWrBv+eUkoH5jGmeV9tQiYQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Dear Kevin Cernekee,
> On Sat, Aug 25, 2012 at 12:36 PM, Marek Vasut <marex-ynQEQJNshbs@public.gmane.org> wrote:
> > Add DT property "m25p,fast-read" that signalises the particular
> > chip supports "fast read" opcode.
>
> This might be slightly clearer if it is rephrased as:
>
> Add DT property "m25p,fast-read" that signifies whether the "fast
> read" opcode is supported.
What's the difference?
> > +Optional properties:
> > +- m25p,fast-read : Use the "fast read" opcode to read data from the chip
> > instead + of the usual "read" opcode. This opcode isn
> > not supported by + all chips and support for it can
> > not be detected at runtime.
>
> "is not supported"
Thanks
> Are there any modern SPI flash parts that can't handle FAST_READ, or
> is this mostly for compatibility with legacy systems?
We have to support all possibilities, not only "modern systems" .
> > + bool fast_read;
> >
> > - t[0].len = m25p_cmdsz(flash) + FAST_READ_DUMMY_BYTE;
> > + t[0].len = m25p_cmdsz(flash) + (flash->fast_read ? 1 : 0);
>
> Newer devices support a variable number of dummy cycles; increasing
> the number of dummy cycles can allow for higher interface speeds. One
> example is the Macronix MX25L25635F:
>
> http://bit.ly/P9s7UM
Good, but I don't see it supported in the driver, how is this different from
MX25L256E?
Besides, I noticed the fast-read isn't even properly excersized, as it always
reads blocks of 512 bytes, even if it can read any basically length. Why is
that, MTD layer stuff or something?
> It might be worth thinking about how to capture this sort of
> information in the DT properties, even if current versions of m25p80
> only use a small subset of the device capabilities.
They can be added as additional DT props, that should be easy.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2012-08-25 20:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-25 19:36 [PATCH V5] mtd: m25p80: Make fast read configurable via DT Marek Vasut
2012-08-25 19:36 ` Marek Vasut
2012-08-25 20:22 ` Kevin Cernekee
2012-08-25 20:22 ` Kevin Cernekee
2012-08-25 20:40 ` Marek Vasut [this message]
2012-08-25 20:40 ` Marek Vasut
2012-08-25 22:06 ` Kevin Cernekee
2012-08-25 22:06 ` Kevin Cernekee
2012-08-26 9:11 ` Marek Vasut
2012-08-26 9:11 ` Marek Vasut
2012-09-04 0:04 ` Marek Vasut
2012-09-04 0:04 ` Marek Vasut
2012-09-17 14:10 ` Marek Vasut
2012-09-17 14:10 ` Marek Vasut
2012-09-21 13:19 ` Artem Bityutskiy
2012-09-21 13:19 ` Artem Bityutskiy
2012-09-24 1:30 ` Marek Vasut
2012-09-24 1:30 ` Marek Vasut
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=201208252240.54932.marex@denx.de \
--to=marex@denx.de \
--cc=artem.bityutskiy@linux.intel.com \
--cc=cernekee@gmail.com \
--cc=david.woodhouse@intel.com \
--cc=dedekind1@gmail.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=linux-mtd@lists.infradead.org \
--cc=robherring2@gmail.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.