From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Lee Jones <lee.jones@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, arnd@arndb.de,
linus.walleij@stericsson.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.cz>
Subject: Re: [PATCH v2] serial: pl011: Add Device Tree support to request DMA channels
Date: Thu, 18 Apr 2013 10:00:09 +0100 [thread overview]
Message-ID: <20130418090008.GG14496@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20130418083922.GC3137@gmail.com>
On Thu, Apr 18, 2013 at 09:39:22AM +0100, Lee Jones wrote:
> On Thu, 18 Apr 2013, Russell King - ARM Linux wrote:
> > This suffers the same problem with your MMCI patch. If you're using DT and
> > don't provide the DMA information, you get errors printed. That's not on
> > for an optional driver feature, especially when that feature causes
> > functional difficulties on various platforms and so is _purposely_ omitted.
>
> How does that differ from using pdata and not passing DMA information?
If you have pdata but no DMA information then, this gets triggered:
if (!plat || !plat->dma_filter) {
dev_info(uap->port.dev, "no DMA platform data\n");
return;
}
However, with your change, this becomes:
if (!(plat && plat->dma_filter) && !np) {
dev_info(uap->port.dev, "no DMA platform data or DT\n");
return;
}
wihch means it is _unconditionally_ bypassed if there is a DT node. So,
if the MMC device has been created from DT, we will drop through to the
following code irrespective of whether there is any DMA data passed.
Hence, we get to here unconditionally in the DT case:
chan = dma_request_slave_channel_compat(mask,
(plat) ? plat->dma_filter : NULL,
(plat) ? plat->dma_tx_param : NULL,
uap->port.dev, "tx");
if (!chan) {
dev_err(uap->port.dev, "no TX DMA channel!\n");
return;
and if the DT transmit DMA information is not provided, chan will be NULL,
which means we produce an error level "no TX DMA channel!" message. That
message is supposed to indicate only when it has not been possible to
request the channel, not when there has been no DMA information provided.
This is where AMBA drivers differ from the majority of other drivers -
DMA is *strictly* optional for them, and that must remain the case as long
as we have platforms where AMBA devices are not hooked up to DMA engines
or where the DMA engines they are hooked up to are buggy, or the entire
DMA design (PL08x connected to PL18x) is buggy.
next prev parent reply other threads:[~2013-04-18 9:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 8:14 Lee Jones
2013-04-18 8:18 ` Russell King - ARM Linux
2013-04-18 8:39 ` Lee Jones
2013-04-18 9:00 ` Russell King - ARM Linux [this message]
2013-04-20 10:33 ` Arnd Bergmann
2013-04-21 8:53 ` Russell King - ARM Linux
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=20130418090008.GG14496@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.cz \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@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 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®