From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/17] of: add dma-mask binding
Date: Wed, 14 Nov 2012 21:05:39 +0000 [thread overview]
Message-ID: <20121114210539.GL3290@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <50A4056E.9090700@gmail.com>
On Wed, Nov 14, 2012 at 02:56:14PM -0600, Rob Herring wrote:
> On 11/14/2012 12:00 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 21:55 Tue 13 Nov , Rob Herring wrote:
> >> On 11/12/2012 02:52 AM, Wenyou Yang wrote:
> >>> +
> >>> + dev->dma_mask = &dev->coherent_dma_mask;
> >>
> >> I don't really know, but I suspect this is wrong.
> > no this is correct was suggest by Russell
> > we already do so on other ARM or SH as example
> >
> > the dma expect a pointer for dma_mask but the value is the same as coherent
>
> Okay. Then perhaps this part should be a separate patch as that is
> useful on its own for 32-bit machines with no DMA address restrictions
> (most modern ARM h/w).
I'm not sure that I did make the exact suggestion being alluded to above
(I think I may have made the suggestion that dev->dma_mask should be
pointed at a dma_mask, and it might be a good idea that it should be
part of struct device.)
I've always shy'd away from making it the same thing as the coherent
DMA mask, because there are drivers around which modify the value
pointed to by dev->dma_mask via standard DMA API calls. (Eg, when they
know that the device is only N-bit capable.)
With that set to the same as dev->coherent_dma_mask, it ends up
modifying the coherent DMA mask too which may or may not be entirely
a good thing; I suspect ultimately that depends on the driver.
My thoughts on this though is that the whole thing is a mess. I'm
not sure why we ended up with a separate coherent_dma_mask from the
main dma_mask, and why we ended up with dma_mask being a pointer to
something allocated elsewhere... it all seems like it's unnecessarily
complicated and was designed to cause confusion...
next prev parent reply other threads:[~2012-11-14 21:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 8:52 [PATCH 00/17] atmel SoC SPI controller with dmaengine and DT Wenyou Yang
2012-11-12 8:52 ` [PATCH 01/17] of: add dma-mask binding Wenyou Yang
2012-11-14 3:55 ` Rob Herring
2012-11-14 6:00 ` Jean-Christophe PLAGNIOL-VILLARD
2012-11-14 20:56 ` Rob Herring
2012-11-14 21:05 ` Russell King - ARM Linux [this message]
2012-11-12 8:52 ` [PATCH 02/17] of_spi: add generic binding support to specify cs gpio Wenyou Yang
2012-11-12 8:52 ` [PATCH 03/17] spi/atmel_spi: add physical base address Wenyou Yang
2012-11-12 8:52 ` [PATCH 04/17] spi/atmel_spi: call unmapping on transfers buffers Wenyou Yang
2012-11-12 8:52 ` [PATCH 05/17] spi/atmel_spi: status information passed through controller data Wenyou Yang
2012-11-12 8:52 ` [PATCH 06/17] spi/atmel_spi: add flag to controller data for lock operations Wenyou Yang
2012-11-15 9:36 ` Shubhrajyoti Datta
2012-11-12 8:52 ` [PATCH 07/17] spi/atmel_spi: add dmaengine support Wenyou Yang
2012-11-12 8:52 ` [PATCH 08/17] spi/atmel_spi: Fix spi-atmel driver to adapt to slave_config changes Wenyou Yang
2012-11-12 8:52 ` [PATCH 09/17] spi/atmel_spi: correct 16 bits transfers using PIO Wenyou Yang
2012-11-12 8:52 ` [PATCH 10/17] spi/atmel_spi: correct 16 bits transfer with DMA Wenyou Yang
2012-11-12 8:52 ` [PATCH 11/17] spi/atmel_spi: add DT support Wenyou Yang
2012-11-12 8:52 ` [PATCH 12/17] spi/atmel_spi: add version propety as the spi data Wenyou Yang
2012-11-12 8:52 ` [PATCH 13/17] spi/atmel_spi: add function to read the spi data from the dts Wenyou Yang
2012-11-12 8:52 ` [PATCH 14/17] ARM: at91: add clocks for spi DT entries Wenyou Yang
2012-11-12 8:52 ` [PATCH 15/17] ARM: dts: add spi nodes for atmel SoC Wenyou Yang
2012-11-12 8:52 ` [PATCH 16/17] ARM: dts: add spi nodes for atmel boards Wenyou Yang
2012-11-12 8:52 ` [PATCH 17/17] mtd: m25p80: change the m25p80_read to reading page to page Wenyou Yang
2012-11-12 9:12 ` Baruch Siach
2012-11-16 6:45 ` Yang, Wenyou
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=20121114210539.GL3290@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).