From: Brian Norris <computersforpeace@gmail.com>
To: Michal Suchanek <hramrach@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
Mark Brown <broonie@kernel.org>,
MTD Maling List <linux-mtd@lists.infradead.org>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>
Subject: Re: RfC: Handle SPI controller limitations like maximum message length
Date: Fri, 20 Nov 2015 15:07:43 -0800 [thread overview]
Message-ID: <20151120230743.GZ64635@google.com> (raw)
In-Reply-To: <CAOMqctQo58yCfzU3u=u3N0zNfhQph2Pw2vnrxsVvAEXi5n2HRw@mail.gmail.com>
Hi Michal,
On Fri, Nov 20, 2015 at 01:56:21PM +0100, Michal Suchanek wrote:
> I was dealing
> with a driver that can transfer up to 63 bytes because it has 64byte
> fifo and the hardware locks up when it's full. The limitation is only
> due to the driver cutting way too many corners. There is dmaengine
> support available for the platform which has been merged recently so
> the driver can use DMA for arbitrarily long transfers. Even without
> DMA there is possibility to to drive CS manually and compose multiple
> transfers into single logical message or whatever.
>
> Either way, the limit of 63 bytes is very low and would actually cause
> problems with many device drivers so it was agreed that fixing the
> master one way or another is desirable.
Thanks for clarifying what your underlying SPI driver/controller
limitations are. I've probably heard this before, but it's hard to keep
track. This helps me review your MTD/SPI-NOR patches better.
All in all, I believe this is not acceptable for SPI NOR. Even if things
"mostly work" by limiting messages to 64 (or 63) bytes, I don't think
they are good in the long run, since the flash may respond differently
to sub-256-byte writes than to 256+ byte writes. I mentioned some of
this in reply to your other patches, but I think a SPI NOR driver would
just have to reject you if you can't even transfer one flash page of
data.
> 64k limit on the other hand is something more usable from driver
> writer standpoint and some banked mmap access to flash memories would
> have similar granularity.
Right.
> I would also like to point out that the limit depends on the transfer
> settings. For example, a SPI controller can have no limit on transfer
> size but when accessing a flash memory through mmap interface the mmap
> window limits the amount of data you can transfer at once. This
> particular case may be fixable by moving the mmap window transparently
> inside the driver.
Hmm, I'm not sure I have much opinion on that one without having a
non-theoretical case. It seems like it'd be best if the SPI master
driver can work as best as it can to respect a single reasonable "max
mesage size", even if that means choosing the lowest common denominator
of all limitations.
Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Michal Suchanek <hramrach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Heiner Kallweit
<hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
MTD Maling List
<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: RfC: Handle SPI controller limitations like maximum message length
Date: Fri, 20 Nov 2015 15:07:43 -0800 [thread overview]
Message-ID: <20151120230743.GZ64635@google.com> (raw)
In-Reply-To: <CAOMqctQo58yCfzU3u=u3N0zNfhQph2Pw2vnrxsVvAEXi5n2HRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Michal,
On Fri, Nov 20, 2015 at 01:56:21PM +0100, Michal Suchanek wrote:
> I was dealing
> with a driver that can transfer up to 63 bytes because it has 64byte
> fifo and the hardware locks up when it's full. The limitation is only
> due to the driver cutting way too many corners. There is dmaengine
> support available for the platform which has been merged recently so
> the driver can use DMA for arbitrarily long transfers. Even without
> DMA there is possibility to to drive CS manually and compose multiple
> transfers into single logical message or whatever.
>
> Either way, the limit of 63 bytes is very low and would actually cause
> problems with many device drivers so it was agreed that fixing the
> master one way or another is desirable.
Thanks for clarifying what your underlying SPI driver/controller
limitations are. I've probably heard this before, but it's hard to keep
track. This helps me review your MTD/SPI-NOR patches better.
All in all, I believe this is not acceptable for SPI NOR. Even if things
"mostly work" by limiting messages to 64 (or 63) bytes, I don't think
they are good in the long run, since the flash may respond differently
to sub-256-byte writes than to 256+ byte writes. I mentioned some of
this in reply to your other patches, but I think a SPI NOR driver would
just have to reject you if you can't even transfer one flash page of
data.
> 64k limit on the other hand is something more usable from driver
> writer standpoint and some banked mmap access to flash memories would
> have similar granularity.
Right.
> I would also like to point out that the limit depends on the transfer
> settings. For example, a SPI controller can have no limit on transfer
> size but when accessing a flash memory through mmap interface the mmap
> window limits the amount of data you can transfer at once. This
> particular case may be fixable by moving the mmap window transparently
> inside the driver.
Hmm, I'm not sure I have much opinion on that one without having a
non-theoretical case. It seems like it'd be best if the SPI master
driver can work as best as it can to respect a single reasonable "max
mesage size", even if that means choosing the lowest common denominator
of all limitations.
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-11-20 23:08 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-18 21:19 RfC: Handle SPI controller limitations like maximum message length Heiner Kallweit
2015-11-18 21:19 ` Heiner Kallweit
2015-11-18 21:57 ` Mark Brown
2015-11-18 21:57 ` Mark Brown
2015-11-18 22:50 ` Heiner Kallweit
2015-11-18 22:50 ` Heiner Kallweit
2015-11-19 11:40 ` Mark Brown
2015-11-19 11:40 ` Mark Brown
2015-11-19 15:00 ` Martin Sperl
2015-11-19 15:00 ` Martin Sperl
2015-11-19 17:15 ` Mark Brown
2015-11-19 17:15 ` Mark Brown
2015-11-20 0:07 ` Brian Norris
2015-11-20 0:07 ` Brian Norris
2015-11-20 11:06 ` Mark Brown
2015-11-20 11:06 ` Mark Brown
2015-11-20 11:16 ` Martin Sperl
2015-11-20 11:16 ` Martin Sperl
2015-11-20 10:18 ` Martin Sperl
2015-11-20 10:18 ` Martin Sperl
2015-11-20 12:05 ` Mark Brown
2015-11-20 12:05 ` Mark Brown
2015-11-20 12:56 ` Martin Sperl
2015-11-20 12:56 ` Martin Sperl
2015-11-21 13:49 ` Mark Brown
2015-11-21 13:49 ` Mark Brown
2015-11-21 14:10 ` Heiner Kallweit
2015-11-21 14:10 ` Heiner Kallweit
2015-11-21 15:57 ` Michal Suchanek
2015-11-21 15:57 ` Michal Suchanek
2015-11-21 22:59 ` [PATCH 0/3] spi: mtd: Handle HW message length restrictions Heiner Kallweit
2015-11-21 22:59 ` Heiner Kallweit
2015-11-21 23:01 ` [PATCH 1/3] spi: core: add max_msg_size to spi_master Heiner Kallweit
2015-11-21 23:01 ` Heiner Kallweit
2015-11-22 13:16 ` Mark Brown
2015-11-22 13:16 ` Mark Brown
2015-11-22 16:15 ` Heiner Kallweit
2015-11-22 16:15 ` Heiner Kallweit
2015-11-23 11:38 ` Mark Brown
2015-11-23 11:38 ` Mark Brown
2015-11-27 19:26 ` Heiner Kallweit
2015-11-27 19:26 ` Heiner Kallweit
2015-11-30 16:42 ` Mark Brown
2015-11-30 16:42 ` Mark Brown
2015-11-30 20:15 ` Heiner Kallweit
2015-11-30 20:15 ` Heiner Kallweit
2015-11-21 23:08 ` [PATCH 2/3] mtd: m25p80: handle HW message size restrictions Heiner Kallweit
2015-11-21 23:08 ` Heiner Kallweit
2015-11-22 12:51 ` Michal Suchanek
2015-11-22 12:51 ` Michal Suchanek
2015-11-21 23:11 ` [PATCH 3/3] spi: fsl-espi: make use of max_msg_size in spi_master to handle HW restrictions Heiner Kallweit
2015-11-21 23:11 ` Heiner Kallweit
2015-11-30 20:24 ` [PATCH v2 1/2] spi: core: add max_msg_size to spi_master Heiner Kallweit
2015-11-30 20:24 ` Heiner Kallweit
2015-11-30 20:25 ` [PATCH resubmit 2/2] spi: fsl-espi: make use of max_msg_size in spi_master to handle HW restrictions Heiner Kallweit
2015-11-30 20:25 ` Heiner Kallweit
2015-12-01 14:19 ` Mark Brown
2015-12-01 14:19 ` Mark Brown
2015-12-01 18:53 ` Heiner Kallweit
2015-12-01 18:53 ` Heiner Kallweit
2015-11-22 13:19 ` RfC: Handle SPI controller limitations like maximum message length Mark Brown
2015-11-22 13:19 ` Mark Brown
2015-11-20 0:02 ` Brian Norris
2015-11-20 0:02 ` Brian Norris
2015-11-20 6:59 ` Heiner Kallweit
2015-11-20 6:59 ` Heiner Kallweit
2015-11-20 10:06 ` Heiner Kallweit
2015-11-20 10:06 ` Heiner Kallweit
2015-11-20 12:35 ` Mark Brown
2015-11-20 12:35 ` Mark Brown
2015-11-20 18:59 ` Heiner Kallweit
2015-11-20 18:59 ` Heiner Kallweit
2015-11-20 19:05 ` Michal Suchanek
2015-11-20 19:05 ` Michal Suchanek
2015-11-20 19:21 ` Mark Brown
2015-11-20 19:21 ` Mark Brown
2015-11-20 19:44 ` Michal Suchanek
2015-11-20 19:44 ` Michal Suchanek
2015-11-20 23:22 ` Brian Norris
2015-11-20 23:22 ` Brian Norris
2015-11-21 22:53 ` Heiner Kallweit
2015-11-21 22:53 ` Heiner Kallweit
2015-11-20 19:18 ` Mark Brown
2015-11-20 19:18 ` Mark Brown
2015-11-20 19:37 ` Heiner Kallweit
2015-11-20 19:37 ` Heiner Kallweit
2015-11-20 12:31 ` Mark Brown
2015-11-20 12:31 ` Mark Brown
2015-11-20 12:56 ` Michal Suchanek
2015-11-20 12:56 ` Michal Suchanek
2015-11-20 23:07 ` Brian Norris [this message]
2015-11-20 23:07 ` Brian Norris
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=20151120230743.GZ64635@google.com \
--to=computersforpeace@gmail.com \
--cc=broonie@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=hramrach@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
/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.