devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@impinj.com>
To: "broonie@kernel.org" <broonie@kernel.org>
Cc: "nicolas.ferre@microchip.com" <nicolas.ferre@microchip.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"radu.pirea@microchip.com" <radu.pirea@microchip.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
	"robh@kernel.org" <robh@kernel.org>,
	"cyrille.pitchen@wedev4u.fr" <cyrille.pitchen@wedev4u.fr>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>,
	"boris.brezillon@free-electrons.com"
	<boris.brezillon@free-electrons.com>,
	"richard@nod.at" <richard@nod.at>,
	marek.vasut@gmai
Subject: Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI
Date: Wed, 27 Dec 2017 20:15:11 +0000	[thread overview]
Message-ID: <1514405711.26695.67.camel@impinj.com> (raw)
In-Reply-To: <20171227103609.GQ1827@finisterre>

On Wed, 2017-12-27 at 10:36 +0000, Mark Brown wrote:
> On Tue, Dec 26, 2017 at 06:45:28PM +0000, Trent Piepho wrote:
> 
> > Or, since this only fixes instances of DMA-unsafe buffers used in
> > access to SPI NOR flash chips, and since there are other SPI master
> > interface users, those chip specific fixes in some/all spi master
> > drivers are still needed to fix transfers not originated via spi-nor? 
> 
> SPI client drivers are *supposed* to use DMA safe memory already.  How
> often that happens in cases where it matters is a separate question, we
> definitely have users with smaller transfers that don't do the right
> thing but they're normally done using PIO anyway.

I wonder what the end goal is here?

A random collection of spi master drivers will accept DMA-unsafe
buffers in some way.  In some cases a framework like spi-nor provides
the fixup to spi-nor master drivers (none so far) and in other cases
(atmel-quadspi), the spi-nor master driver has its own fixes.

Generic spi masters like spi-atmel, spi-ti-qspi, and spi-davinci will
have their fixes for certain cases.

Perhaps spi flash drivers like m25p80 will have fixes too?

Some spi clients, like spidev, will have internal bounce buffers,
rather than userspace addresses or commands in stack variables, so that
they follow the rules about DMA safe buffers.

What exactly is caught as DMA unsafe and what is not will of course
vary greatly from driver to driver.  Some drivers will catch highmem
memory while other drivers will only detect vmalloc memory.  Some will
only catch an unsafe buffer if a specific SoC known to the driver to
have an aliasing cache is enabled.  Some will check buffers that arrive
via the spi_flash_read interface but not via generic spi transfers,
while others will check all spi transfer buffers.

Obviously, I don't think this path will lead to a desirable end.  Maybe
the basic assumption, that clients should provide DMA safe buffers,
should be revisited.  Experience has shown that it's too much to ask
for and spi clients will never get it right.  It would be better to try
to fix this at some common point between the clients and masters so it
can be done once and for all.

  reply	other threads:[~2017-12-27 20:15 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-24  4:36 [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI Cyrille Pitchen
2017-12-24  4:36 ` [PATCH 1/3] mtd: spi-nor: add optional DMA-safe bounce buffer for data transfer Cyrille Pitchen
     [not found]   ` <fc2440c6f52877f28286d89691049e5cba10e6a7.1514087323.git.cyrille.pitchen-yU5RGvR974pGWvitb5QawA@public.gmane.org>
2017-12-26 13:42     ` Vignesh R
     [not found]       ` <1126731d-cbf7-8fbf-34ab-8ccf1cc8241f-l0cyMroinI0@public.gmane.org>
2017-12-26 13:59         ` Cyrille Pitchen
     [not found]           ` <ae977280-28b4-d746-da4b-0f807dad609d-yU5RGvR974pGWvitb5QawA@public.gmane.org>
2018-01-07 20:07             ` Boris Brezillon
2017-12-26 19:43     ` Trent Piepho
     [not found]       ` <1514317385.26695.39.camel-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org>
2017-12-28 10:39         ` Cyrille Pitchen
2017-12-28 18:54           ` Trent Piepho
     [not found]             ` <1514487276.26695.94.camel-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org>
2017-12-29 10:16               ` Vignesh R
     [not found]                 ` <08be8b42-732a-bf28-40c4-f46bf9d71c80-l0cyMroinI0@public.gmane.org>
2017-12-29 18:03                   ` Trent Piepho
2018-01-02 10:00                     ` Vignesh R
2018-01-07 20:49     ` Boris Brezillon
2017-12-24  4:36 ` [PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap, memcpy' Cyrille Pitchen
     [not found]   ` <143542c61ca674d53da4985bbabc142e8e6ebefc.1514087323.git.cyrille.pitchen-yU5RGvR974pGWvitb5QawA@public.gmane.org>
2017-12-26 23:23     ` [PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy' Rob Herring
2017-12-27 21:40       ` Cyrille Pitchen
     [not found]         ` <0149ba05-64b1-2739-e61f-78d5170775fb-yU5RGvR974pGWvitb5QawA@public.gmane.org>
2018-01-02 10:22           ` Ludovic Desroches
     [not found]             ` <20180102102234.GG2612-fC2aZbRiGnsAAwgTK2POJVCF2YAvjlIb@public.gmane.org>
2018-01-02 19:18               ` Trent Piepho
     [not found]                 ` <1514920738.26695.171.camel-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org>
2018-01-03  6:51                   ` ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA
2018-01-03 11:51           ` Mark Brown
2017-12-24  4:36 ` [PATCH 3/3] mtd: atmel-quadspi: add support of DMA memcpy() Cyrille Pitchen
2017-12-26 18:45 ` [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI Trent Piepho
2017-12-27 10:36   ` Mark Brown
2017-12-27 20:15     ` Trent Piepho [this message]
     [not found]       ` <1514405711.26695.67.camel-cgc2CodaaHDQT0dZR+AlfA@public.gmane.org>
2017-12-28  9:36         ` Cyrille Pitchen
2018-01-03 11:49         ` Mark Brown
2017-12-29  9:16   ` 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=1514405711.26695.67.camel@impinj.com \
    --to=tpiepho@impinj.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=broonie@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marek.vasut@gmai \
    --cc=nicolas.ferre@microchip.com \
    --cc=radu.pirea@microchip.com \
    --cc=richard@nod.at \
    --cc=robh@kernel.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 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).