From: Mark Brown <broonie@kernel.org>
To: Michal Suchanek <hramrach@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
linux-sunxi <linux-sunxi@googlegroups.com>,
Maxime Ripard <maxime.ripard@free-electrons.com>,
Chen-Yu Tsai <wens@csie.org>,
linux-spi <linux-spi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/5] RFC spi: sun4i: add DMA support
Date: Mon, 30 May 2016 16:50:16 +0100 [thread overview]
Message-ID: <20160530155016.GO29837@sirena.org.uk> (raw)
In-Reply-To: <CAOMqctQb-YYprA7H5qCcYo2hxXiUhjW2z3JbZ3-FhbfcjFzBpw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote:
> On 30 May 2016 at 17:03, Mark Brown <broonie@kernel.org> wrote:
> > I really don't think it's worth caring too much about cases where the
> > DMA driver hasn't been compiled in, it's not like SPI is the only thing
> It's what the driver did to start with and it was requested to fall
> back to non-DMA in the case DMA is not available.
Why? I really can't see any sensible use case for this that doesn't
have a better solution available.
> It's possible to add a parameter like require_dma which could be used
> to load the driver without dma if unset. If it was set by default then
> driver ordering is not important so long as dma driver is loaded
> eventually. Also an informative print that such parameter exists when
> probing the driver is deferred would be helpful. It would probably
> create quite a bit of log spam, however. The driver can be deferred
> several times during boot.
That seems fairly hacky, if we were going to do anything like that it
should be the other way around so that we default to trying to use
resources and even then it seems like something that should be handled
at a framework level rather than having random options in individual
drivers to ignore things. Having things behave inconsistently between
different drivers is going to lead to a worse user experience and if
this is a good idea for one driver it seems like it'd be a good idea for
all of them.
But really
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-05-30 15:50 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1464130597.git.hramrach@gmail.com>
[not found] ` <cb90b922caa6ac07c1425d726ea19709ee5284f4.1464130597.git.hramrach@gmail.com>
2016-05-27 2:05 ` [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout Julian Calaby
2016-05-27 5:05 ` Michal Suchanek
2016-05-27 5:10 ` Julian Calaby
2016-05-30 11:23 ` Mark Brown
2016-05-31 11:52 ` Michal Suchanek
2016-06-01 18:20 ` Maxime Ripard
2016-05-30 9:44 ` Maxime Ripard
[not found] ` <e315008b5e9dc3f1490507508fd2f6e94767dfbb.1464130597.git.hramrach@gmail.com>
2016-05-30 8:37 ` [PATCH 2/5] spi: sun4i: fix FIFO limit Maxime Ripard
[not found] ` <5fffb7eca6f4b70853d92be2403595d6d06bede7.1464130597.git.hramrach@gmail.com>
2016-05-30 8:37 ` [PATCH 3/5] spi: sunxi: expose maximum transfer size limit Maxime Ripard
2016-05-30 8:57 ` Michal Suchanek
2016-06-01 18:14 ` Maxime Ripard
[not found] ` <7292b1fa08de4f453a643beb63e9faa7826726f6.1464130597.git.hramrach@gmail.com>
2016-05-30 9:17 ` [PATCH 4/5] spi: sunxi: set maximum and minimum speed of SPI master Maxime Ripard
[not found] ` <ba0d6eb37cc4b0d2c46acbf9fcd7d644b3545ce8.1464130597.git.hramrach@gmail.com>
2016-05-30 11:26 ` [PATCH 5/5] RFC spi: sun4i: add DMA support Mark Brown
2016-05-30 12:11 ` Geert Uytterhoeven
2016-05-30 15:03 ` Mark Brown
2016-05-30 15:28 ` Michal Suchanek
2016-05-30 15:50 ` Mark Brown [this message]
2016-05-31 10:44 ` Michal Suchanek
2016-05-31 13:27 ` Mark Brown
2016-05-31 14:19 ` Michal Suchanek
2016-06-02 8:18 ` Maxime Ripard
2016-06-01 18:00 ` Maxime Ripard
2016-06-02 4:42 ` [linux-sunxi] " Priit Laes
2016-06-02 9:18 ` Mark Brown
2016-06-02 12:14 ` Michal Suchanek
2016-06-02 14:26 ` Mark Brown
2016-06-05 11:27 ` Michal Suchanek
2016-06-06 11:36 ` Mark Brown
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=20160530155016.GO29837@sirena.org.uk \
--to=broonie@kernel.org \
--cc=geert@linux-m68k.org \
--cc=hramrach@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=maxime.ripard@free-electrons.com \
--cc=wens@csie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®