From: Michal Suchanek <hramrach@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: "R, Vignesh" <vigneshr@ti.com>,
devicetree <devicetree@vger.kernel.org>,
Brian Norris <computersforpeace@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
Tony Lindgren <tony@atomide.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
Huang Shijie <b32955@freescale.com>,
MTD Maling List <linux-mtd@lists.infradead.org>,
linux-omap@vger.kernel.org, David Woodhouse <dwmw2@infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read
Date: Thu, 6 Aug 2015 13:42:32 +0200 [thread overview]
Message-ID: <CAOMqctQKc6f5Mbe_CSd-ghguUfZvf6v_BRvYxQJVqPne73iESA@mail.gmail.com> (raw)
In-Reply-To: <20150806112353.GT20873@sirena.org.uk>
On 6 August 2015 at 13:23, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote:
>
>> However, I am familiar m25p80.c and as I understand it the controller
>> is basically supposed to implement m25p80.c in hardware when this flag
>> is set.
>
> But what in concrete terms is that supposed to mean? It's currently
> just an essentially undocumented flag on a message rather than something
> operating at the level of a flash chip. That's pretty much where
> Russell's comments come from.
>
>> If I was using m25p80.c to talk to anything but an actual flash chip
>> it would get me quite worried.
>
> Sure, but at the end of the day it's just emitting standard SPI messages
> which don't know anything about flash. If those messages are a sensible
> interface here then why bother with the flag, we can just pattern match
> on the format of the message. If that doesn't work then probably this
> isn't a great interface and a separate, application specific interface
> makes more sense.
The messages are sensible interface for communicating with a device
that interprets a particular part of the mesasge as address and
another particular part of the message as command and sends same
amount of junk before reply as the flash chip would. If your device
happens to send reply immediately part of it is trashed. If it happens
to interpret address differently the data ends up in random part of
your memory. So no, that is not something you can autodetect.
At the end of the day you have valid SPI messages but the m25p80 layer
adds interpretation to those messages which may not always give
correct result.
On the other hand, if you ever get to m25p80 or spi-nor you can assume
any message you send goes to a flash chip and insist that the
controller uses the flash-specific interface.
If there is possibility of connecting different kind of devices to
multiple chipselects on the same master then you probably want to
select this option per message or per slave.
Thanks
Michal
next prev parent reply other threads:[~2015-08-06 11:42 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 8:41 [RFC PATCH 0/5] Add memory mapped read support for TI QSPI Vignesh R
2015-07-28 8:41 ` [RFC PATCH 1/5] spi: introduce flag for memory mapped read Vignesh R
2015-07-31 18:17 ` Mark Brown
2015-08-03 4:57 ` Vignesh R
2015-08-04 15:51 ` Mark Brown
[not found] ` <20150804155148.GR20873-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-08-04 17:59 ` R, Vignesh
[not found] ` <55C0FD98.1090107-l0cyMroinI0@public.gmane.org>
2015-08-05 5:21 ` Michal Suchanek
2015-08-05 5:35 ` Vignesh R
[not found] ` <55C1A095.8000509-l0cyMroinI0@public.gmane.org>
2015-08-05 5:57 ` Michal Suchanek
2015-08-05 11:50 ` Mark Brown
[not found] ` <20150805115013.GJ20873-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-08-05 12:40 ` Michal Suchanek
[not found] ` <CAOMqctQXwcHyiWBwtugSDSE_k65qrNfrwnhjQMDJkLoJMmGzUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-05 12:44 ` Mark Brown
2015-08-05 12:56 ` Michal Suchanek
2015-08-06 9:02 ` Mark Brown
2015-08-06 10:01 ` Michal Suchanek
[not found] ` <CAOMqctQZRZ4zG_yYy=CeX3DX4NVNWN1COP4Q-2YvMun9xYOA7g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-06 10:22 ` Russell King - ARM Linux
2015-08-06 11:00 ` Mark Brown
[not found] ` <20150806102225.GI7576-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-08-06 11:02 ` Michal Suchanek
2015-08-06 12:25 ` Vignesh R
2015-08-06 13:51 ` Russell King - ARM Linux
[not found] ` <20150806135129.GJ7576-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-08-06 16:14 ` Geert Uytterhoeven
[not found] ` <CAMuHMdWWDwZ=ziGQXFCnOX8pErXpsEi533J73_Hh=sEqq4hR6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-06 18:20 ` Michal Suchanek
2015-08-06 21:33 ` Russell King - ARM Linux
[not found] ` <20150806213340.GK7576-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-08-07 7:38 ` Michal Suchanek
2015-08-07 8:35 ` Vignesh R
2015-08-07 8:25 ` Martin Sperl
2015-08-07 10:16 ` Michal Suchanek
[not found] ` <CAOMqctScUybdoZPgqH185qzDxB=TyutDMARextHx0XwC7L3Xmw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-08-12 9:27 ` Vignesh R
2015-08-06 16:46 ` Mark Brown
2015-08-06 18:20 ` Mark Brown
2015-08-06 11:23 ` Mark Brown
2015-08-06 11:42 ` Michal Suchanek [this message]
2015-08-06 16:03 ` Mark Brown
2015-07-28 8:41 ` [RFC PATCH 2/5] spi: spi-ti-qspi: Add memory mapped read support Vignesh R
2015-07-28 8:41 ` [RFC PATCH 3/5] mtd: devices: m25p80: set flag to request memory mapped read Vignesh R
2015-07-28 8:41 ` [RFC PATCH 4/5] ARM: dts: DRA7: Add memory map region entries for qspi Vignesh R
2015-07-31 13:48 ` Sekhar Nori
[not found] ` <55BB7CA4.1020300-l0cyMroinI0@public.gmane.org>
2015-08-03 5:09 ` Vignesh R
2015-07-31 18:19 ` Mark Brown
[not found] ` <20150731181903.GN20873-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-08-03 5:02 ` Vignesh R
[not found] ` <55BEF5D1.1050608-l0cyMroinI0@public.gmane.org>
2015-08-04 15:52 ` Mark Brown
2015-07-31 21:28 ` Brian Norris
[not found] ` <20150731212847.GH10676-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2015-08-03 5:06 ` Vignesh R
2015-07-28 8:41 ` [RFC PATCH 5/5] ARM: dts: AM4372: " Vignesh R
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=CAOMqctQKc6f5Mbe_CSd-ghguUfZvf6v_BRvYxQJVqPne73iESA@mail.gmail.com \
--to=hramrach@gmail.com \
--cc=b32955@freescale.com \
--cc=broonie@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=tony@atomide.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).