linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/7] of: setup dma parameters using dma-ranges and dma-coherent
Date: Sat, 19 Apr 2014 18:25:28 +0200	[thread overview]
Message-ID: <20140419182528.414b9b2e@skate> (raw)
In-Reply-To: <1397917972-6293-1-git-send-email-santosh.shilimkar@ti.com>

Dear Santosh Shilimkar,

On Sat, 19 Apr 2014 10:32:45 -0400, Santosh Shilimkar wrote:
> Here is an updated version of [2] based on discussion. Series introduces
> support for setting up dma parameters based on device tree properties
> like 'dma-ranges' and 'dma-coherent' and also update to ARM 32 bit port.
> Earlier version of the same series is here [1].
> 
> The 'dma-ranges' helps to take care of few DMAable system memory restrictions
> by use of dma_pfn_offset which we maintain now per device. Arch code then
> uses it for dma address translations for such cases. We update the
> dma_pfn_offset accordingly during DT the device creation process.The
> 'dma-coherent' property is used to setup arch's coherent dma_ops.
> 
> After some off-list discussion with RMK and Arnd, I have now dropped the
> controversial dma_mask setup code from the series which actually isn't blocking
> me as such. Considering rest of the parts of the series are already aligned,
> am hoping to get this version merged for 3.16 merge window.
> 
> We agreed in last discussion that drivers have the ultimate
> responsibility to setup the correct dma mask but then we need to have some
> means to see if bus can support what driver has requested for a case where
> driver request for bigger mask than what bus supports. I can follow up on
> the mask topic if we have broken drivers.

I am not sure whether there is an intersection or not, but I wanted to
mention that the mvebu platform (in mach-mvebu) supports hardware I/O
coherency, which makes it a coherent DMA platform. However, we are not
able to use arm_coherent_dma_ops for this platform, because when a
transfer is being made DMA_FROM_DEVICE, at the end of the transfer, we
need to perform an I/O barrier to wait for the snooping unit to
complete its coherency work. So we're coherent, but not with
arm_coherent_dma_ops: we have our own dma operation implementation (see
arch/arm/mach-mvebu/coherency.c).

However, it seems that your patch series, at least in PATCH 6/7 makes
the assumption that for all DMA coherent platforms,
arm_coherent_dma_ops is going to be OK.

Also, I haven't followed all the discussions, but what is the intended
usage of of_dma_is_coherent() and set_arch_dma_coherent_ops() (device
drivers? platform code?).

In mach-mvebu, what we do is that we register a bus notifier on the
platform bus, so that we can set our custom DMA operations for all
platform devices in the system. Should this be done in a different way
after your series?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  parent reply	other threads:[~2014-04-19 16:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-19 14:32 [PATCH v2 0/7] of: setup dma parameters using dma-ranges and dma-coherent Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 1/7] device: introduce per device dma_pfn_offset Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 2/7] of: introduce of_dma_get_range() helper Santosh Shilimkar
2014-04-21 15:29   ` Rob Herring
2014-04-22 14:56     ` Grygorii Strashko
2014-04-22  4:09   ` Joel Fernandes
2014-04-19 14:32 ` [PATCH v2 3/7] of: introduce of_dma_is_coherent() helper Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 4/7] of: configure the platform device dma parameters Santosh Shilimkar
2014-04-21 14:58   ` Rob Herring
2014-04-22 15:09     ` Grygorii Strashko
2014-04-22 14:44       ` Rob Herring
2014-04-22 15:44         ` Grygorii Strashko
2014-04-19 14:32 ` [PATCH v2 5/7] ARM: dma: Use dma_pfn_offset for dma address translation Santosh Shilimkar
2014-04-19 19:43   ` Russell King - ARM Linux
2014-04-21 13:38     ` Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 6/7] ARM: dma: implement set_arch_dma_coherent_ops() Santosh Shilimkar
2014-04-19 14:32 ` [PATCH v2 7/7] ARM: mm: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu] Santosh Shilimkar
2014-04-21 13:39   ` Santosh Shilimkar
2014-04-19 16:25 ` Thomas Petazzoni [this message]
2014-04-21 13:35   ` [PATCH v2 0/7] of: setup dma parameters using dma-ranges and dma-coherent Santosh Shilimkar
2014-04-21 18:19     ` Thomas Petazzoni
2014-04-21 19:17       ` Santosh Shilimkar
2014-04-22 14:54   ` Catalin Marinas
2014-04-22 15:02   ` Arnd Bergmann
2014-04-22 15:15     ` Santosh Shilimkar
2014-04-22 15:25     ` Catalin Marinas
2014-04-22 15:30       ` Rob Herring
2014-04-22 16:01         ` Catalin Marinas
2014-04-21 14:37 ` Rob Herring
2014-04-21 15:13   ` Santosh Shilimkar
2014-04-21 15:35     ` Rob Herring
2014-04-21 15:36       ` Santosh Shilimkar

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=20140419182528.414b9b2e@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --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).