[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140501132516.GG26756@n2100.arm.linux.org.uk>
Date: Thu, 1 May 2014 14:25:16 +0100
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Santosh Shilimkar <santosh.shilimkar@...com>
Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
Grant Likely <grant.likely@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Linus Walleij <linus.walleij@...aro.org>,
Grygorii Strashko <grygorii.strashko@...com>
Subject: Re: [PATCH v3 0/7] of: setup dma parameters using dma-ranges and
dma-coherent
On Thu, May 01, 2014 at 09:19:18AM -0400, Santosh Shilimkar wrote:
> Rob, Russell,
>
> On Thursday 24 April 2014 11:30 AM, Santosh Shilimkar wrote:
> > Here is an updated v3 of the series. 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
> > series can be found here [3], [2] and [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.
> >
> > Hopefully with acks, tested-by this version can get into 3.16 queue. I will
> > post a followup series for Keystone SOC which will use this infrastructure.
> > Linus W also wants to use this for ARM integrator platform dma offset issue.
> >
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Cc: Russell King <linux@....linux.org.uk>
> > Cc: Arnd Bergmann <arnd@...db.de>
> > Cc: Olof Johansson <olof@...om.net>
> > Cc: Grant Likely <grant.likely@...aro.org>
> > Cc: Rob Herring <robh+dt@...nel.org>
> > Cc: Catalin Marinas <catalin.marinas@....com>
> > Cc: Linus Walleij <linus.walleij@...aro.org>
> > Cc: Grygorii Strashko <grygorii.strashko@...com>
> >
> > Grygorii Strashko (2):
> > of: introduce of_dma_get_range() helper
> > ARM: dma: Use dma_pfn_offset for dma address translation
> >
> > Santosh Shilimkar (5):
> > device: introduce per device dma_pfn_offset
> > of: introduce of_dma_is_coherent() helper
> > of: configure the platform device dma parameters
> > ARM: dma: implement set_arch_dma_coherent_ops()
> > ARM: dma: use phys_addr_t in __dma_page_[cpu_to_dev/dev_to_cpu]
> >
> > arch/arm/include/asm/dma-mapping.h | 28 ++++++++++--
> > arch/arm/mm/dma-mapping.c | 4 +-
> > drivers/of/address.c | 87 ++++++++++++++++++++++++++++++++++++
> > drivers/of/platform.c | 71 +++++++++++++++++++++++++++--
> > include/linux/device.h | 2 +
> > include/linux/dma-mapping.h | 7 +++
> > include/linux/of_address.h | 8 ++++
> > include/linux/of_platform.h | 6 +++
> > 8 files changed, 204 insertions(+), 9 deletions(-)
> >
> How do we go about merging this series ? There is a dependency
> between the patches and hence the question.
I don't know anymore. People today want to assert exclusive rights over
parts of the kernel tree, which makes this kind of cross-patching rather
impossible.
The only workable solution I can see is the long winded way to split the
series up, merge the first set of dependencies in one merge window, and
hold the rest back for the following merge window. Not ideal, but it
stops the arguments.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists