* [PATCH] timer: vt8500: Convert vt8500 to use CLKSRC_OF
From: Olof Johansson @ 2013-01-15 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358232649-19964-1-git-send-email-linux@prisktech.co.nz>
On Tue, Jan 15, 2013 at 07:50:49PM +1300, Tony Prisk wrote:
> This patch converts arch-vt8500 to make use of CLKSRC_OF. Doing so
> removes the need for include/linux/vt8500_timer.h as vt8500_timer_init
> no longer needs to be visible outside vt8500_timer.c
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> Hi Olof,
>
> Here is the fix as requested by Stephen Warren, based on vt8500/timer.
Applied, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] imx fixes for 3.8, take 2
From: Olof Johansson @ 2013-01-15 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115134337.GA6574@S2101-09.ap.freescale.net>
On Tue, Jan 15, 2013 at 09:43:38PM +0800, Shawn Guo wrote:
> The following changes since commit e37f0d5b32c2a66677d0f2a21431a87e7e9ce22d:
>
> ARM: mx5: Fix MX53 flexcan2 clock (2013-01-08 08:53:07 +0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.8-2
Pulled into fixes, thanks.
-Olof
^ permalink raw reply
* [PATCH 4/4] ARM: uncompress: support uncompress debug for multiplatform build
From: Olof Johansson @ 2013-01-15 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130112032934.GA14865@S2101-09.ap.freescale.net>
On Sat, Jan 12, 2013 at 11:29:37AM +0800, Shawn Guo wrote:
> On Fri, Jan 11, 2013 at 11:11:16AM -0800, Olof Johansson wrote:
> > Hi,
> >
> > On Wed, Dec 12, 2012 at 09:45:45PM +0800, Shawn Guo wrote:
> > > When moving to multiplatform build, platforms lose the output from
> > > decompressor. Not only does it mean that we will never see message
> > > "Uncompressing Linux... done, booting the kernel.", but also that
> > > the debug facility in arch/arm/boot/compressed/head.S outputs nothing
> > > even DEBUG is turned on.
> > >
> > > The patch follows the approach handling DEBUG_LL to create a Kconfig
> > > symbol CONFIG_UNCOMPRESS_INCLUDE for choosing the correct uncompress
> > > header. For traditional build, mach/uncompress.h will be included in
> > > arch/arm/boot/compressed/misc.c. For multiplatform build with none
> > > DEBUG_LL port enabled, debug/uncompress/dummy.h will be used. And
> > > for multiplatform build with a DEBUG_LL port, platform specific
> > > uncompress header like debug/uncompress/imx.h will come to play.
> > >
> > > Different from traditional build that uncompress output and DEBUG_LL
> > > are two separated pieces, for multiplatform build uncompress output
> > > becomes a subset of DEBUG_LL and will not work unless DEBUG_LL is
> > > enabled.
> > >
> > > The arch/arm/include/debug/uncompress/imx.h is cleaned up and added
> > > here as an example to show how this approach works.
> >
> > Since this requires you to define a debug uart to get uncompress output,
> > it would make more sense to do a generic wrapper that uses the debug
> > code generically, instead of having to add this kind of wrapper for
> > every platform. That would solve it for all of them at once.
> >
> I'm not entirely sure about what you mean here. Can you please
> elaborate that generic wrapper in your mind a little bit?
Hi,
Sorry for the delay in responding.
Most functionality to deal with this already exist in the
include/debug/*.S files files, you just need to instantiate the macros
somewhere (compressed/head.S, or a separate file), and wrap the calls
to those instantiated assembly functions in a generic header file.
That way, every platform that has a DEBUG_LL implementation should be able to
reuse that, and no need to enable every platform one by one.
Or am I missing some complexity involved here?
-Olof
^ permalink raw reply
* [Linaro-mm-sig][RFC] ARM: dma-mapping: Add DMA attribute to skip iommu mapping
From: Arnd Bergmann @ 2013-01-15 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F570A4.70606@samsung.com>
On Tuesday 15 January 2013, Marek Szyprowski wrote:
> I'm sorry, but from my perspective this patch and the yet another dma
> attribute shows that there is something fishy happening in the exynos-drm
> driver. Creating a mapping in DMA address space is the MAIN purpose of
> the DMA mapping subsystem, so adding an attribute which skips this
> operation already should give you a sign of warning that something is
> not used right.
>
> It looks that dma-mapping in the current state is simply not adequate
> for this driver. I noticed that DRM drivers are already known for
> implementing a lots of common code for their own with slightly changed
> behavior, like custom page manager/allocator. It looks that exynos-drm
> driver grew to the point where it also needs such features. It already
> contains custom code for CPU cache handling, IOMMU and contiguous
> memory special cases management. I would advise to drop DMA-mapping
> API completely, avoid adding yet another dozen of DMA attributes useful
> only for one driver and implement your own memory manager with direct
> usage of IOMMU API, alloc_pages() and dma_alloc_pages_from_contiguous().
> This way DMA mapping subsystem can be kept simple, robust and easy to
> understand without confusing or conflicting parts.
Makes sense. DRM drivers and KVM are the two cases where you typically
want to use the iommu API rather than the dma-mapping API, because you
need protection between multiple concurrent user contexts.
Arnd
^ permalink raw reply
* [PATCH 06/16] ARM: b.L: generic SMP secondary bringup and hotplug support
From: Dave Martin @ 2013-01-15 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301141145350.6300@xanadu.home>
On Mon, Jan 14, 2013 at 11:51:11AM -0500, Nicolas Pitre wrote:
> On Mon, 14 Jan 2013, Will Deacon wrote:
>
> > On Thu, Jan 10, 2013 at 12:20:41AM +0000, Nicolas Pitre wrote:
> > > Now that the b.L power API is in place, we can use it for SMP secondary
> > > bringup and CPU hotplug in a generic fashion.
> >
> > [...]
> >
> > > diff --git a/arch/arm/common/bL_platsmp.c b/arch/arm/common/bL_platsmp.c
> > > new file mode 100644
> > > index 0000000000..0acb9f4685
> > > --- /dev/null
> > > +++ b/arch/arm/common/bL_platsmp.c
> > > @@ -0,0 +1,79 @@
> > > +/*
> > > + * linux/arch/arm/mach-vexpress/bL_platsmp.c
> > > + *
> > > + * Created by: Nicolas Pitre, November 2012
> > > + * Copyright: (C) 2012 Linaro Limited
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License version 2 as
> > > + * published by the Free Software Foundation.
> > > + *
> > > + * Code to handle secondary CPU bringup and hotplug for the bL power API.
> > > + */
> > > +
> > > +#include <linux/init.h>
> > > +#include <linux/smp.h>
> > > +
> > > +#include <asm/bL_entry.h>
> > > +#include <asm/smp_plat.h>
> > > +#include <asm/hardware/gic.h>
> > > +
> > > +static void __init simple_smp_init_cpus(void)
> > > +{
> > > + set_smp_cross_call(gic_raise_softirq);
> > > +}
> > > +
> > > +static int __cpuinit bL_boot_secondary(unsigned int cpu, struct task_struct *idle)
> > > +{
> > > + unsigned int pcpu, pcluster, ret;
> > > + extern void secondary_startup(void);
> > > +
> > > + pcpu = cpu_logical_map(cpu) & 0xff;
> > > + pcluster = (cpu_logical_map(cpu) >> 8) & 0xff;
> >
> > Again, you can probably use Lorenzo's helpers here.
>
> Yes, that goes for the whole series.
>
> > > + pr_debug("%s: logical CPU %d is physical CPU %d cluster %d\n",
> > > + __func__, cpu, pcpu, pcluster);
> > > +
> > > + bL_set_entry_vector(pcpu, pcluster, NULL);
> >
> > Now that you don't have a barrier in this function, you need one here.
>
> Hmmm... Why?
In effect, we are entering a critical section here: that's precisely
why we close the gate.
We need a barrier after bL_set_entry_vector() to make sure that no
operations from the critical section leak outside from the
perspective of the target CPU.
Similarly, we need a barrier before bL_set_entry_vector() when
opening the gate.
The corresponding barrier required in bL_head.S at bL_entry_gated
is added by my recent barriers and tidyups series.
Closing and opening the gate are a bit like taking and releasing
a lock -- which is one reason for having simple wrapper functions
to make these roles more obvious.
>
> > > + ret = bL_cpu_power_up(pcpu, pcluster);
> > > + if (ret)
> > > + return ret;
> >
> > and here, although I confess to not understanding why you write NULL the
> > first time.
>
> If for some reasons the bL_cpu_power_up() call fails, I don't want this
> CPU to suddenly decide to enter the kernel if it wakes up at a later
> time when secondary_startup is not ready to deal with it anymore.
>
> > > + bL_set_entry_vector(pcpu, pcluster, secondary_startup);
> > > + gic_raise_softirq(cpumask_of(cpu), 0);
> > > + sev();
> >
> > This relise on the event register being able to be set if the target is in a
> > low-power (wfi) state. I'd feel safer with a dsb before the sev...
The sev() signals the update to the entry vector, which has already been
DSB'd by the flushing in bL_set_entry_vector().
Also, the relative order of gic_raise_softirq() and sev() here is
not important, provided they both follow bL_set_entry_vector().
There are no circumstances under which we could know whether the
IRQ or SEV arrives first at the destination CPU anyway. A DSB is
insufficient since the store may still not have arrived at the GIC;
but even doing a readback from the GIC isn't enough, because the
relationships and relative speed of the underlying interrupt and
SEV signalling mechanisms are not architecturally visible.
The crucial thing is that the SEV does not arrive before the destination
CPU has observed the modification to the entry vector -- that could
cause the target CPU to stall in WFE.
If the CPU powers up after missing the SEV, that's fine, because the
observability of the non-NULL entry vector is guaranteed by the
flushing which precedes gic_raise_softirq(). SEV is only important
if the CPU powers up early, observes a NULL entry vector and goes
into WFE.
Because this code only applies with the multiprocessing extensions,
we know that the writes associated with gic_raise_softirq() will
drain and take effect eventually, but we don't care when. We
can't know the results for sure until the target CPU re-enters the
kernel.
Cheers
---Dave
^ permalink raw reply
* [PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data
From: Artem Bityutskiy @ 2013-01-15 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115185251.GB14149@atomide.com>
On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote:
> Artem,
>
> Looks like this patch related to making GPMC work with DT was
> never sent to linux-mtd or to you so adding to cc.
>
> Is this OK to apply along with the GPMC patches, or do you want to
> take this separately with the MTD patches?
Please, go ahead!
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/b2da5b95/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] mtd: vt8500: Add support for Wondermedia Serial Flash Controller
From: Artem Bityutskiy @ 2013-01-15 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358271907.31593.1.camel@gitbox>
On Wed, 2013-01-16 at 06:45 +1300, Tony Prisk wrote:
> On Tue, 2013-01-15 at 16:55 +0200, Artem Bityutskiy wrote:
> > On Mon, 2012-12-31 at 10:00 +1300, Tony Prisk wrote:
> > > This patch adds support for the Wondermedia serial flash controller
> > > found on WM8505, WM8650 and WM8850 SoCs.
> > >
> > > Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> > > ---
> > > v2: Whitespace tidyup
> >
> > Hi, would you please take a look at these warings, identified by aiaiai:
> >
> > Successfully built configuration "x86_64_defconfig,x86_64,", results:
> >
> > --- before_patching.log
> > +++ after_patching.log
> > @@ @@
> > +drivers/mtd/devices/wmt_sflash.c: In function ?sf_read?:
> > +drivers/mtd/devices/wmt_sflash.c:425:9: warning: format ?%d? expects argument of type ?int?, but argument 4 has type ?size_t? [-Wformat]
> > +drivers/mtd/devices/wmt_sflash.c: In function ?sf_sector_write?:
> > +drivers/mtd/devices/wmt_sflash.c:442:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> > +drivers/mtd/devices/wmt_sflash.c:442:24: warning: cast removes address space of expression [sparse]
> > +drivers/mtd/devices/wmt_sflash.c:458:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > +drivers/mtd/devices/wmt_sflash.c:458:31: warning: incorrect type in argument 1 (different address spaces) [sparse]
> > +drivers/mtd/devices/wmt_sflash.c:458:31: expected void volatile [noderef] <asn:2>*dst [sparse]
> > +drivers/mtd/devices/wmt_sflash.c:458:31: got unsigned char [usertype] *<noident> [sparse]
> > +drivers/mtd/devices/wmt_sflash.c:465:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > +drivers/mtd/devices/wmt_sflash.c:465:39: warning: incorrect type in argument 1 (different address spaces) [sparse]
> > +drivers/mtd/devices/wmt_sflash.c:465:39: expected void volatile [noderef] <asn:2>*dst [sparse]
> > +drivers/mtd/devices/wmt_sflash.c:465:39: got unsigned char [usertype] *<noident> [sparse]
> >
>
> Apologies - This driver shouldn't be selectable for x86_64.
> It is an ARM driver for an embedded device. Will fix.
Note, there are also warnings when it is compiled for other platforms,
not only x86_64. Take a look at them. Also note, than many warnings come
from sparse, you probably just did not run it.
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/fcf878d1/attachment.sig>
^ permalink raw reply
* [GIT PULL] ste_dma40 updates for 3.9
From: Olof Johansson @ 2013-01-15 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZh=5FBDCuSFWYw8t-1Snm1xuS_EyVTUyQ-8kwVgjWuPA@mail.gmail.com>
On Tue, Jan 15, 2013 at 09:53:05AM +0100, Linus Walleij wrote:
> On Tue, Jan 15, 2013 at 7:48 AM, Olof Johansson <olof@lixom.net> wrote:
>
> > This series of patches only modify the ste_dma40 driver, there are no
> > corresponding changes under arch/arm that need to be coordinated or
> > considered w.r.t. merge conflicts. I.e. they all seem nicely isolated
> > to only the driver.
> >
> > So is there a specific reason for why these shouldn't just go in
> > through the dmaengine tree?
>
> One reason would be if there are DMA bindings to device tree coming
> this merge window, as I'm told, and it implicates a lot of platform code
> changes on top of this as we adopt to it.
>
> But maybe this will be wholly confined to the DMAengine tree?
Changing platform code in the driver trees is asking for conflicts at
merge time and a grumpy Linus, I'd prefer to merge arch/arm/* through
arm-soc in that case.
Either way, this branch can be merged into dmaengine as a branch pull,
and if needed we can bring it in as a dependency on arm-soc. We would
need the same for the dmaengine DT bindings branch as a base. Of course,
that requires that Vinod doesn't rebase his branch and keeps the merge
intact. Vinod, is that compatible with your workflow?
-Olof
^ permalink raw reply
* [PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data
From: Tony Lindgren @ 2013-01-15 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358276967.1668.0.camel@kyv>
* Artem Bityutskiy <dedekind1@gmail.com> [130115 11:12]:
> On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote:
> > Artem,
> >
> > Looks like this patch related to making GPMC work with DT was
> > never sent to linux-mtd or to you so adding to cc.
> >
> > Is this OK to apply along with the GPMC patches, or do you want to
> > take this separately with the MTD patches?
>
> Please, go ahead!
OK thanks. Can I add your Acked-by too?
Tony
^ permalink raw reply
* [PATCH] arm: mxs: Update mxs_defconfig
From: Fabio Estevam @ 2013-01-15 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121225132304.GA25478@S2101-09.ap.freescale.net>
Shawn,
On Tue, Dec 25, 2012 at 11:23 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> Applied with one comment below to Fabio.
Which tree this was applied?
I would like to make another update and base my patch on top of Marek's patch.
^ permalink raw reply
* [PATCH v8 2/5] mtd: omap-nand: pass device_node in platform data
From: Artem Bityutskiy @ 2013-01-15 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115192624.GD14149@atomide.com>
On Tue, 2013-01-15 at 11:26 -0800, Tony Lindgren wrote:
> * Artem Bityutskiy <dedekind1@gmail.com> [130115 11:12]:
> > On Tue, 2013-01-15 at 10:52 -0800, Tony Lindgren wrote:
> > > Artem,
> > >
> > > Looks like this patch related to making GPMC work with DT was
> > > never sent to linux-mtd or to you so adding to cc.
> > >
> > > Is this OK to apply along with the GPMC patches, or do you want to
> > > take this separately with the MTD patches?
> >
> > Please, go ahead!
>
> OK thanks. Can I add your Acked-by too?
Yes Tony, please, do:
Acked-by: Artem Bityutskiy <dedekind1@gmail.com>
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/b7b40c11/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] mtd: vt8500: Add support for Wondermedia Serial Flash Controller
From: Artem Bityutskiy @ 2013-01-15 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358272414-6266-1-git-send-email-linux@prisktech.co.nz>
On Wed, 2013-01-16 at 06:53 +1300, Tony Prisk wrote:
> This patch adds support for the Wondermedia serial flash controller
> found on WM8505, WM8650 and WM8850 SoCs.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Would please you also send a defconfig which I can use to compile-test
this?
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130115/d1537fdc/attachment.sig>
^ permalink raw reply
* [PATCH 0/6] arm: mvebu: Add support for USB host controllers in Armada 370/XP
From: Florian Fainelli @ 2013-01-15 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F5289D.80903@free-electrons.com>
Hello Ezequiel,
On Tuesday 15 January 2013 06:59:57 Ezequiel Garcia wrote:
> Hi,
>
> This small patch set enables USB support on Armada 370 and Armada XP platforms.
> It's based on Jason Cooper's mvebu/dt branch.
>
> Any comments or feedback are welcome.
I successfully tested this serie on a Marvell RD-A370-A1 and a DB-MV784MP-GP:
Tested-by: Florian Fainelli <florian@openwrt.org>
Thanks!
>
> Ezequiel Garcia (6):
> arm: mvebu: Add support for USB host controllers in Armada 370/XP
> arm: mvebu: Enable USB controllers on Armada 370 evaluation board
> arm: mvebu: Enable USB controllers on Armada 370 Mirabox board
> arm: mvebu: Enable USB controllers on Armada XP evaluation board
> arm: mvebu: Enable USB controllers on Armada XP OpenBlocks AX3-4 board
> arm: mvebu: Update defconfig to select USB support
>
> arch/arm/boot/dts/armada-370-db.dts | 8 ++++++++
> arch/arm/boot/dts/armada-370-mirabox.dts | 8 ++++++++
> arch/arm/boot/dts/armada-370-xp.dtsi | 15 +++++++++++++++
> arch/arm/boot/dts/armada-370.dtsi | 9 +++++++++
> arch/arm/boot/dts/armada-xp-db.dts | 12 ++++++++++++
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 9 +++++++++
> arch/arm/boot/dts/armada-xp.dtsi | 17 +++++++++++++++++
> arch/arm/configs/mvebu_defconfig | 5 ++++-
> arch/arm/mach-mvebu/Kconfig | 1 +
> 9 files changed, 83 insertions(+), 1 deletions(-)
>
> Thanks!
>
>
--
Florian
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Sebastian Hesselbarth @ 2013-01-15 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115165642.GA25500@titan.lakedaemon.net>
On 01/15/2013 05:56 PM, Jason Cooper wrote:
> Greg,
>
> I've added you to the this thread hoping for a little insight into USB
> drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
> wrong tree by looking a the drivers?
>
> On Mon, Jan 14, 2013 at 12:56:57PM +0100, Soeren Moch wrote:
>> On 20.11.2012 15:31, Marek Szyprowski wrote:
>>> dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,
>>> regardless the flags provided by the caller. This causes excessive
>>> pruning of emergency memory pools without any good reason. Additionaly,
>>> on ARM architecture any driver which is using dmapools will sooner or
>>> later trigger the following error:
>>> "ERROR: 256 KiB atomic DMA coherent pool is too small!
>>> Please increase it with coherent_pool= kernel parameter!".
>>> Increasing the coherent pool size usually doesn't help much and only
>>> delays such error, because all GFP_ATOMIC DMA allocations are always
>>> served from the special, very limited memory pool.
>>>
>>> This patch changes the dmapool code to correctly use gfp flags provided
>>> by the dmapool caller.
>>>
>>> Reported-by: Soeren Moch<smoch@web.de>
>>> Reported-by: Thomas Petazzoni<thomas.petazzoni@free-electrons.com>
>>> Signed-off-by: Marek Szyprowski<m.szyprowski@samsung.com>
>>> Tested-by: Andrew Lunn<andrew@lunn.ch>
>>> Tested-by: Soeren Moch<smoch@web.de>
>>
>> Now I tested linux-3.7.1 (this patch is included there) on my Marvell
>> Kirkwood system. I still see
>>
>> ERROR: 1024 KiB atomic DMA coherent pool is too small!
>> Please increase it with coherent_pool= kernel parameter!
>>
>> after several hours of runtime under heavy load with SATA and
>> DVB-Sticks (em28xx / drxk and dib0700).
>
> Could you try running the system w/o the em28xx stick and see how it
> goes with v3.7.1?
Jason,
can you point out what you think we should be looking for?
I grep'd for 'GFP_' in drivers/media/usb and especially for dvb-usb
(dib0700) it looks like most of the buffers in usb-urb.c are allocated
GFP_ATOMIC. em28xx also allocates some of the buffers atomic.
If we look for a mem leak in one of the above drivers (including sata_mv),
is there an easy way to keep track of allocated and freed kernel memory?
Sebastian
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Jason Cooper @ 2013-01-15 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130115175020.GA3764@kroah.com>
On Tue, Jan 15, 2013 at 09:50:20AM -0800, Greg KH wrote:
> On Tue, Jan 15, 2013 at 11:56:42AM -0500, Jason Cooper wrote:
> > Greg,
> >
> > I've added you to the this thread hoping for a little insight into USB
> > drivers and their use of coherent and GFP_ATOMIC. Am I barking up the
> > wrong tree by looking a the drivers?
>
> I don't understand, which drivers are you referring to? USB host
> controller drivers, or the "normal" drivers?
Sorry I wasn't clear, I was referring specifically to the usb dvb
drivers em28xx, drxk and dib0700. These are the drivers reported to be
in heavy use when the error occurs.
sata_mv is also in use, however no other users of sata_mv have reported
problems. Including myself. ;-)
> Most USB drivers use GFP_ATOMIC if they are creating memory during
> their URB callback path, as that is interrupt context. But it
> shouldn't be all that bad, and the USB core hasn't changed in a while,
> so something else must be causing this.
Agreed, so I went and did more reading. The key piece of the puzzle
that I was missing was in arch/arm/mm/dma-mapping.c 660-684.
/*
* Allocate DMA-coherent memory space and return both the kernel
* remapped
* virtual and bus address for that space.
*/
void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
gfp_t gfp, struct dma_attrs *attrs)
{
pgprot_t prot = __get_dma_pgprot(attrs, pgprot_kernel);
void *memory;
if (dma_alloc_from_coherent(dev, size, handle, &memory))
return memory;
return __dma_alloc(dev, size, handle, gfp, prot, false,
__builtin_return_address(0));
}
static void *arm_coherent_dma_alloc(struct device *dev, size_t size,
dma_addr_t *handle, gfp_t gfp, struct dma_attrs *attrs)
{
pgprot_t prot = __get_dma_pgprot(attrs, pgprot_kernel);
void *memory;
if (dma_alloc_from_coherent(dev, size, handle, &memory))
return memory;
return __dma_alloc(dev, size, handle, gfp, prot, true,
__builtin_return_address(0));
}
My understanding of this code is that when a driver requests dma memory,
we will first try to alloc from the per-driver pool. If that fails, we
will then attempt to allocate from the atomic_pool.
Once the atomic_pool is exhausted, we get the error:
ERROR: 1024 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!
If my understanding is correct, one of the drivers (most likely one)
either asks for too small of a dma buffer, or is not properly
deallocating blocks from the per-device pool. Either case leads to
exhaustion, and falling back to the atomic pool. Which subsequently
gets wiped out as well.
Am I on the right track?
thx,
Jason.
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Jason Cooper @ 2013-01-15 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F5B69E.1070101@gmail.com>
On Tue, Jan 15, 2013 at 09:05:50PM +0100, Sebastian Hesselbarth wrote:
> If we look for a mem leak in one of the above drivers (including sata_mv),
> is there an easy way to keep track of allocated and freed kernel memory?
I'm inclined to think sata_mv is not the cause here, as there are many
heavy users of it without error reports. The only thing different here
are the three usb dvb dongles.
thx,
Jason.
^ permalink raw reply
* [PATCH v5 00/14] DMA Engine support for AM33XX
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
Changes since v4:
- Fixed debug section mismatch in private edma api [01/14]
- Respun format-patch to catch the platform_data/edma.h rename [01/14]
- Removed address/size-cells from the EDMA binding [05/14]
Changes since v3:
- Rebased on 3.8-rc3
- No longer an RFC
- Fixed bugs in DT/pdata parsing reported by Vaibhav Bedia
- Restored all the Davinci pdata to const
- Removed max_segs hack in favor of using dma_get_channel_caps()
- Fixed extra parens, __raw_* accessors and, ioremap error checks
in xbar handling
- Removed excess license info in platform_data/edma.h
- Removed unneeded reserved channels data for AM33xx
- Removed test-specific pinmuxing from dts files
- Adjusted mmc1 node to be disabled by default in the dtsi
Changes since v2:
- Rebased on 3.7-rc1
- Fixed bug in DT/pdata parsing first found by Gururaja
that turned out to be masked by some toolchains
- Dropped unused mach-omap2/devices.c hsmmc patch
- Added AM33XX crossbar DMA event mux support
- Added am335x-evm support
Changes since v1:
- Rebased on top of mainline from 12250d8
- Dropped the feature removal schedule patch
- Implemented dma_request_slave_channel_compat() and
converted the mmc and spi drivers to use it
- Dropped unneeded #address-cells and #size-cells from
EDMA DT support
- Moved private EDMA header to linux/platform_data/ and
removed some unneeded definitions
- Fixed parsing of optional properties
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
The series applies on top of 3.8-rc3 and the following patches:
- TPS65910 REGMAP_IRQ build fix:
https://patchwork.kernel.org/patch/1857701/
- dmaengine DT support from Vinod's dmaengine_dt branch in
git://git.infradead.org/users/vkoul/slave-dma.git since
027478851791df751176398be02a3b1c5f6aa824
- edma dmaengine driver fix:
https://patchwork.kernel.org/patch/1961521/
- dmaengine dma_get_channel_caps v2:
https://patchwork.kernel.org/patch/1961601/
- dmaengine edma driver channel caps support v2:
https://patchwork.kernel.org/patch/1961591/
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
With this series both BeagleBone and the AM335x EVM have working
MMC and SPI support.
This is tested on BeagleBone with a SPI framebuffer driver and MMC
rootfs. A trivial gpio DMA event misc driver was used to test the
crossbar DMA event support. It is also tested on the AM335x EVM
with the onboard SPI flash and MMC rootfs. The branch at
https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v4
has the complete series, dependencies, and some test
drivers/defconfigs.
Regression testing was done on AM180x-EVM (which also makes use
of the EDMA dmaengine driver and the EDMA private API) using SD,
SPI flash, and the onboard audio supported by the ASoC Davinci
driver. Regression testing was also done on a BeagleBoard xM
booting from the legacy board file using MMC rootfs.
Matt Porter (14):
ARM: davinci: move private EDMA API to arm/common
ARM: edma: remove unused transfer controller handlers
ARM: edma: add AM33XX support to the private EDMA API
dmaengine: edma: enable build for AM33XX
dmaengine: edma: Add TI EDMA device tree binding
ARM: dts: add AM33XX EDMA support
dmaengine: add dma_request_slave_channel_compat()
mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
mmc: omap_hsmmc: set max_segs based on dma engine limitations
mmc: omap_hsmmc: add generic DMA request support to the DT binding
ARM: dts: add AM33XX MMC support
spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
spi: omap2-mcspi: add generic DMA request support to the DT binding
ARM: dts: add AM33XX SPI DMA support
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +-
Documentation/devicetree/bindings/spi/omap-spi.txt | 28 +-
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/am335x-bone.dts | 7 +
arch/arm/boot/dts/am335x-evm.dts | 7 +
arch/arm/boot/dts/am335x-evmsk.dts | 7 +
arch/arm/boot/dts/am33xx.dtsi | 58 ++++
arch/arm/common/Kconfig | 3 +
arch/arm/common/Makefile | 1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} | 355 +++++++++++++++++---
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c | 2 +-
arch/arm/mach-davinci/davinci.h | 2 +-
arch/arm/mach-davinci/devices-tnetv107x.c | 2 +-
arch/arm/mach-davinci/devices.c | 7 +-
arch/arm/mach-davinci/dm355.c | 2 +-
arch/arm/mach-davinci/dm365.c | 2 +-
arch/arm/mach-davinci/dm644x.c | 2 +-
arch/arm/mach-davinci/dm646x.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/plat-omap/Kconfig | 1 +
drivers/dma/Kconfig | 2 +-
drivers/dma/edma.c | 2 +-
drivers/mmc/host/davinci_mmc.c | 1 +
drivers/mmc/host/omap_hsmmc.c | 16 +-
drivers/spi/spi-omap2-mcspi.c | 65 ++--
include/linux/dmaengine.h | 10 +
include/linux/mfd/davinci_voicecodec.h | 3 +-
.../mach => include/linux/platform_data}/edma.h | 90 +----
include/linux/platform_data/spi-davinci.h | 2 +-
sound/soc/davinci/davinci-evm.c | 1 +
sound/soc/davinci/davinci-pcm.c | 1 +
sound/soc/davinci/davinci-pcm.h | 2 +-
sound/soc/davinci/davinci-sffsdr.c | 6 +-
35 files changed, 588 insertions(+), 180 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (85%)
rename {arch/arm/mach-davinci/include/mach => include/linux/platform_data}/edma.h (59%)
--
1.7.9.5
^ permalink raw reply
* [PATCH v5 01/14] ARM: davinci: move private EDMA API to arm/common
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API and enables it to build on OMAP.
Signed-off-by: Matt Porter <mporter@ti.com>
---
arch/arm/Kconfig | 1 +
arch/arm/common/Kconfig | 3 +
arch/arm/common/Makefile | 1 +
arch/arm/{mach-davinci/dma.c => common/edma.c} | 4 +-
arch/arm/mach-davinci/Makefile | 2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c | 2 +-
arch/arm/mach-davinci/davinci.h | 2 +-
arch/arm/mach-davinci/devices-tnetv107x.c | 2 +-
arch/arm/mach-davinci/devices.c | 7 +-
arch/arm/mach-davinci/dm355.c | 2 +-
arch/arm/mach-davinci/dm365.c | 2 +-
arch/arm/mach-davinci/dm644x.c | 2 +-
arch/arm/mach-davinci/dm646x.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/plat-omap/Kconfig | 1 +
drivers/dma/edma.c | 2 +-
drivers/mmc/host/davinci_mmc.c | 1 +
include/linux/mfd/davinci_voicecodec.h | 3 +-
.../mach => include/linux/platform_data}/edma.h | 89 +-------------------
include/linux/platform_data/spi-davinci.h | 2 +-
sound/soc/davinci/davinci-evm.c | 1 +
sound/soc/davinci/davinci-pcm.c | 1 +
sound/soc/davinci/davinci-pcm.h | 2 +-
sound/soc/davinci/davinci-sffsdr.c | 6 +-
24 files changed, 33 insertions(+), 109 deletions(-)
rename arch/arm/{mach-davinci/dma.c => common/edma.c} (99%)
rename {arch/arm/mach-davinci/include/mach => include/linux/platform_data}/edma.h (59%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP) += scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..be3c04a 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include <linux/io.h>
#include <linux/slab.h>
-#include <mach/edma.h>
+#include <linux/platform_data/edma.h>
/* Offsets matching "struct edmacc_param" */
#define PARM_OPT 0x00
@@ -1387,7 +1387,7 @@ EXPORT_SYMBOL(edma_clear_event);
/*-----------------------------------------------------------------------*/
-static int __init edma_probe(struct platform_device *pdev)
+static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info **info = pdev->dev.platform_data;
const s8 (*queue_priority_mapping)[2];
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o psc.o \
- dma.o usb.o common.o sram.o aemif.o
+ usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include <linux/input.h>
#include <linux/input/matrix_keypad.h>
#include <linux/spi/spi.h>
+#include <linux/platform_data/edma.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
#include <mach/irqs.h>
-#include <mach/edma.h>
#include <mach/mux.h>
#include <mach/cp_intc.h>
#include <mach/tnetv107x.h>
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
#include <linux/platform_device.h>
#include <linux/spi/spi.h>
#include <linux/platform_data/davinci_asp.h>
+#include <linux/platform_data/edma.h>
#include <linux/platform_data/keyscan-davinci.h>
#include <mach/hardware.h>
-#include <mach/edma.h>
#include <media/davinci/vpfe_capture.h>
#include <media/davinci/vpif_types.h>
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c b/arch/arm/mach-davinci/devices-tnetv107x.c
index 773ab07..ba37760 100644
--- a/arch/arm/mach-davinci/devices-tnetv107x.c
+++ b/arch/arm/mach-davinci/devices-tnetv107x.c
@@ -18,10 +18,10 @@
#include <linux/dma-mapping.h>
#include <linux/clk.h>
#include <linux/slab.h>
+#include <linux/platform_data/edma.h>
#include <mach/common.h>
#include <mach/irqs.h>
-#include <mach/edma.h>
#include <mach/tnetv107x.h>
#include "clock.h"
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 4c48a36..3bdf9f7 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -19,9 +19,10 @@
#include <mach/irqs.h>
#include <mach/cputype.h>
#include <mach/mux.h>
-#include <mach/edma.h>
#include <linux/platform_data/mmc-davinci.h>
#include <mach/time.h>
+#include <linux/platform_data/edma.h>
+
#include "davinci.h"
#include "clock.h"
@@ -141,10 +142,10 @@ static struct resource mmcsd0_resources[] = {
},
/* DMA channels: RX, then TX */
{
- .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
+ .start = EDMA_CTLR_CHAN(0, 26), /* MMCRXEVT */
.flags = IORESOURCE_DMA,
}, {
- .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCTXEVT),
+ .start = EDMA_CTLR_CHAN(0, 27), /* MMCTXEVT */
.flags = IORESOURCE_DMA,
},
};
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index b49c3b7..53998d8 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -19,7 +19,6 @@
#include <asm/mach/map.h>
#include <mach/cputype.h>
-#include <mach/edma.h>
#include <mach/psc.h>
#include <mach/mux.h>
#include <mach/irqs.h>
@@ -28,6 +27,7 @@
#include <mach/common.h>
#include <linux/platform_data/spi-davinci.h>
#include <mach/gpio-davinci.h>
+#include <linux/platform_data/edma.h>
#include "davinci.h"
#include "clock.h"
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 6c39805..9b41d33 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -18,11 +18,11 @@
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/spi/spi.h>
+#include <linux/platform_data/edma.h>
#include <asm/mach/map.h>
#include <mach/cputype.h>
-#include <mach/edma.h>
#include <mach/psc.h>
#include <mach/mux.h>
#include <mach/irqs.h>
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 11c79a3..a08910e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -12,11 +12,11 @@
#include <linux/clk.h>
#include <linux/serial_8250.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/edma.h>
#include <asm/mach/map.h>
#include <mach/cputype.h>
-#include <mach/edma.h>
#include <mach/irqs.h>
#include <mach/psc.h>
#include <mach/mux.h>
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index ac7b431..6d52a32 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -13,11 +13,11 @@
#include <linux/clk.h>
#include <linux/serial_8250.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/edma.h>
#include <asm/mach/map.h>
#include <mach/cputype.h>
-#include <mach/edma.h>
#include <mach/irqs.h>
#include <mach/psc.h>
#include <mach/mux.h>
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index 700d311..9d77f9b 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -20,8 +20,8 @@
#include <linux/videodev2.h>
#include <mach/serial.h>
-#include <mach/edma.h>
#include <mach/pm.h>
+#include <linux/platform_data/edma.h>
#include <linux/platform_data/i2c-davinci.h>
#include <linux/platform_data/mmc-davinci.h>
#include <linux/platform_data/usb-davinci.h>
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 665870d..0b81d6c 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -29,6 +29,7 @@ config ARCH_OMAP2PLUS
select PINCTRL
select PROC_DEVICETREE if PROC_FS
select SPARSE_IRQ
+ select TI_PRIV_EDMA
select USE_OF
help
"Systems based on OMAP2, OMAP3, OMAP4 or OMAP5"
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 023c8f2..e57cce3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -24,7 +24,7 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
-#include <mach/edma.h>
+#include <linux/platform_data/edma.h>
#include "dmaengine.h"
#include "virt-dma.h"
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 17e186d..d1efacc 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -35,6 +35,7 @@
#include <linux/edma.h>
#include <linux/mmc/mmc.h>
+#include <linux/platform_data/edma.h>
#include <linux/platform_data/mmc-davinci.h>
/*
diff --git a/include/linux/mfd/davinci_voicecodec.h b/include/linux/mfd/davinci_voicecodec.h
index 0ab6132..7dd6524 100644
--- a/include/linux/mfd/davinci_voicecodec.h
+++ b/include/linux/mfd/davinci_voicecodec.h
@@ -26,8 +26,7 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/mfd/core.h>
-
-#include <mach/edma.h>
+#include <linux/platform_data/edma.h>
/*
* Register values.
diff --git a/arch/arm/mach-davinci/include/mach/edma.h b/include/linux/platform_data/edma.h
similarity index 59%
rename from arch/arm/mach-davinci/include/mach/edma.h
rename to include/linux/platform_data/edma.h
index 7e84c90..2344ea2 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -1,28 +1,12 @@
/*
- * TI DAVINCI dma definitions
+ * TI EDMA definitions
*
- * Copyright (C) 2006-2009 Texas Instruments.
+ * Copyright (C) 2006-2013 Texas Instruments.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, write to the Free Software Foundation, Inc.,
- * 675 Mass Ave, Cambridge, MA 02139, USA.
- *
*/
/*
@@ -69,11 +53,6 @@ struct edmacc_param {
unsigned int ccnt;
};
-#define CCINT0_INTERRUPT 16
-#define CCERRINT_INTERRUPT 17
-#define TCERRINT0_INTERRUPT 18
-#define TCERRINT1_INTERRUPT 19
-
/* fields in edmacc_param.opt */
#define SAM BIT(0)
#define DAM BIT(1)
@@ -87,70 +66,6 @@ struct edmacc_param {
#define TCCHEN BIT(22)
#define ITCCHEN BIT(23)
-#define TRWORD (0x7<<2)
-#define PAENTRY (0x1ff<<5)
-
-/* Drivers should avoid using these symbolic names for dm644x
- * channels, and use platform_device IORESOURCE_DMA resources
- * instead. (Other DaVinci chips have different peripherals
- * and thus have different DMA channel mappings.)
- */
-#define DAVINCI_DMA_MCBSP_TX 2
-#define DAVINCI_DMA_MCBSP_RX 3
-#define DAVINCI_DMA_VPSS_HIST 4
-#define DAVINCI_DMA_VPSS_H3A 5
-#define DAVINCI_DMA_VPSS_PRVU 6
-#define DAVINCI_DMA_VPSS_RSZ 7
-#define DAVINCI_DMA_IMCOP_IMXINT 8
-#define DAVINCI_DMA_IMCOP_VLCDINT 9
-#define DAVINCI_DMA_IMCO_PASQINT 10
-#define DAVINCI_DMA_IMCOP_DSQINT 11
-#define DAVINCI_DMA_SPI_SPIX 16
-#define DAVINCI_DMA_SPI_SPIR 17
-#define DAVINCI_DMA_UART0_URXEVT0 18
-#define DAVINCI_DMA_UART0_UTXEVT0 19
-#define DAVINCI_DMA_UART1_URXEVT1 20
-#define DAVINCI_DMA_UART1_UTXEVT1 21
-#define DAVINCI_DMA_UART2_URXEVT2 22
-#define DAVINCI_DMA_UART2_UTXEVT2 23
-#define DAVINCI_DMA_MEMSTK_MSEVT 24
-#define DAVINCI_DMA_MMCRXEVT 26
-#define DAVINCI_DMA_MMCTXEVT 27
-#define DAVINCI_DMA_I2C_ICREVT 28
-#define DAVINCI_DMA_I2C_ICXEVT 29
-#define DAVINCI_DMA_GPIO_GPINT0 32
-#define DAVINCI_DMA_GPIO_GPINT1 33
-#define DAVINCI_DMA_GPIO_GPINT2 34
-#define DAVINCI_DMA_GPIO_GPINT3 35
-#define DAVINCI_DMA_GPIO_GPINT4 36
-#define DAVINCI_DMA_GPIO_GPINT5 37
-#define DAVINCI_DMA_GPIO_GPINT6 38
-#define DAVINCI_DMA_GPIO_GPINT7 39
-#define DAVINCI_DMA_GPIO_GPBNKINT0 40
-#define DAVINCI_DMA_GPIO_GPBNKINT1 41
-#define DAVINCI_DMA_GPIO_GPBNKINT2 42
-#define DAVINCI_DMA_GPIO_GPBNKINT3 43
-#define DAVINCI_DMA_GPIO_GPBNKINT4 44
-#define DAVINCI_DMA_TIMER0_TINT0 48
-#define DAVINCI_DMA_TIMER1_TINT1 49
-#define DAVINCI_DMA_TIMER2_TINT2 50
-#define DAVINCI_DMA_TIMER3_TINT3 51
-#define DAVINCI_DMA_PWM0 52
-#define DAVINCI_DMA_PWM1 53
-#define DAVINCI_DMA_PWM2 54
-
-/* DA830 specific EDMA3 information */
-#define EDMA_DA830_NUM_DMACH 32
-#define EDMA_DA830_NUM_TCC 32
-#define EDMA_DA830_NUM_PARAMENTRY 128
-#define EDMA_DA830_NUM_EVQUE 2
-#define EDMA_DA830_NUM_TC 2
-#define EDMA_DA830_CHMAP_EXIST 0
-#define EDMA_DA830_NUM_REGIONS 4
-#define DA830_DMACH2EVENT_MAP0 0x000FC03Fu
-#define DA830_DMACH2EVENT_MAP1 0x00000000u
-#define DA830_EDMA_ARM_OWN 0x30FFCCFFu
-
/*ch_status paramater of callback function possible values*/
#define DMA_COMPLETE 1
#define DMA_CC_ERROR 2
diff --git a/include/linux/platform_data/spi-davinci.h b/include/linux/platform_data/spi-davinci.h
index 7af305b..8dc2fa47 100644
--- a/include/linux/platform_data/spi-davinci.h
+++ b/include/linux/platform_data/spi-davinci.h
@@ -19,7 +19,7 @@
#ifndef __ARCH_ARM_DAVINCI_SPI_H
#define __ARCH_ARM_DAVINCI_SPI_H
-#include <mach/edma.h>
+#include <linux/platform_data/edma.h>
#define SPI_INTERN_CS 0xFF
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index d55e647..591f547 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -14,6 +14,7 @@
#include <linux/timer.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/edma.h>
#include <linux/i2c.h>
#include <sound/core.h>
#include <sound/pcm.h>
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
index afab81f..9bdd71b 100644
--- a/sound/soc/davinci/davinci-pcm.c
+++ b/sound/soc/davinci/davinci-pcm.c
@@ -17,6 +17,7 @@
#include <linux/dma-mapping.h>
#include <linux/kernel.h>
#include <linux/genalloc.h>
+#include <linux/platform_data/edma.h>
#include <sound/core.h>
#include <sound/pcm.h>
diff --git a/sound/soc/davinci/davinci-pcm.h b/sound/soc/davinci/davinci-pcm.h
index b6ef703..fbb710c 100644
--- a/sound/soc/davinci/davinci-pcm.h
+++ b/sound/soc/davinci/davinci-pcm.h
@@ -14,7 +14,7 @@
#include <linux/genalloc.h>
#include <linux/platform_data/davinci_asp.h>
-#include <mach/edma.h>
+#include <linux/platform_data/edma.h>
struct davinci_pcm_dma_params {
int channel; /* sync dma channel ID */
diff --git a/sound/soc/davinci/davinci-sffsdr.c b/sound/soc/davinci/davinci-sffsdr.c
index 5be65aa..074fc5d 100644
--- a/sound/soc/davinci/davinci-sffsdr.c
+++ b/sound/soc/davinci/davinci-sffsdr.c
@@ -17,6 +17,7 @@
#include <linux/timer.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/edma.h>
#include <linux/gpio.h>
#include <sound/core.h>
#include <sound/pcm.h>
@@ -28,7 +29,6 @@
#include <asm/plat-sffsdr/sffsdr-fpga.h>
#endif
-#include <mach/edma.h>
#include "../codecs/pcm3008.h"
#include "davinci-pcm.h"
@@ -123,8 +123,8 @@ static struct resource sffsdr_snd_resources[] = {
};
static struct evm_snd_platform_data sffsdr_snd_data = {
- .tx_dma_ch = DAVINCI_DMA_MCBSP_TX,
- .rx_dma_ch = DAVINCI_DMA_MCBSP_RX,
+ .tx_dma_ch = 2, /* MCBSP_TX */
+ .rx_dma_ch = 3, /* MCBSP_RX */
};
static struct platform_device *sffsdr_snd_device;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 02/14] ARM: edma: remove unused transfer controller handlers
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter <mporter@ti.com>
---
arch/arm/common/edma.c | 37 -------------------------------------
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be3c04a..2dce245 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/******************************************************************************
- *
- * Transfer controller error interrupt handlers
- *
- *****************************************************************************/
-
-#define tc_errs_handled false /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc0err_handler\n");
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, "dma_tc1err_handler\n");
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int edma_probe(struct platform_device *pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- "edma_tc0", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d failed --> %d\n",
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- "edma_tc1", &pdev->dev);
- if (status < 0) {
- dev_dbg(&pdev->dev, "request_irq %d --> %d\n",
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 03/14] ARM: edma: add AM33XX support to the private EDMA API
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data. Enables runtime PM support to
initialize the EDMA hwmod. Adds AM33XX EMDA crossbar event mux
support.
Signed-off-by: Matt Porter <mporter@ti.com>
---
arch/arm/common/edma.c | 314 ++++++++++++++++++++++++++++++++++--
include/linux/platform_data/edma.h | 1 +
2 files changed, 306 insertions(+), 9 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2dce245..beeb1d2 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/slab.h>
+#include <linux/edma.h>
+#include <linux/err.h>
+#include <linux/of_address.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/of_irq.h>
+#include <linux/pm_runtime.h>
#include <linux/platform_data/edma.h>
@@ -723,6 +730,9 @@ EXPORT_SYMBOL(edma_free_channel);
*/
int edma_alloc_slot(unsigned ctlr, int slot)
{
+ if (!edma_cc[ctlr])
+ return -EINVAL;
+
if (slot >= 0)
slot = EDMA_CHAN_SLOT(slot);
@@ -1366,31 +1376,291 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*-----------------------------------------------------------------------*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+ const char *propname, s8 *out_values,
+ size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s8)(be32_to_cpup(val++) & 0xff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+ const char *propname, s16 *out_values,
+ size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) > prop->length)
+ return -EOVERFLOW;
+
+ val = prop->value;
+
+ while (sz--)
+ *out_values++ = (s16)(be32_to_cpup(val++) & 0xffff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_xbar_event_map(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata, int len)
+{
+ int ret = 0;
+ int i;
+ struct resource res;
+ void *xbar;
+ const s16 (*xbar_chans)[2];
+ u32 shift, offset, mux;
+
+ xbar_chans = devm_kzalloc(dev,
+ len/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!xbar_chans)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 1, &res);
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ xbar = devm_ioremap(dev, res.start, resource_size(&res));
+ if (!xbar)
+ return -ENOMEM;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-xbar-event-map",
+ (s16 *)xbar_chans,
+ len/sizeof(u32));
+ if (IS_ERR_VALUE(ret))
+ return -EIO;
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] >> 2;
+ offset <<= 2;
+ mux = readl((void *)((u32)xbar + offset));
+ mux &= ~(0xff << shift);
+ mux |= xbar_chans[i][0] << shift;
+ writel(mux, (void *)((u32)xbar + offset));
+ }
+
+ pdata->xbar_chans = xbar_chans;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ const s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ const s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ memset(pdata, 0, sizeof(struct edma_soc_info));
+
+ ret = of_property_read_u32(node, "dma-channels", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_channel = value;
+
+ ret = of_property_read_u32(node, "ti,edma-regions", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_region = value;
+
+ ret = of_property_read_u32(node, "ti,edma-slots", &value);
+ if (ret < 0)
+ return ret;
+ pdata->n_slot = value;
+
+ pdata->n_cc = 1;
+ pdata->n_tc = 3;
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata->rsv = rsv_info;
+
+ /* Build the reserved channel/slots arrays */
+ prop = of_find_property(node, "ti,edma-reserved-channels", &sz);
+ if (prop) {
+ rsv_chans = devm_kzalloc(dev,
+ sz/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!rsv_chans)
+ return -ENOMEM;
+ pdata->rsv->rsv_chans = rsv_chans;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-reserved-channels",
+ (s16 *)rsv_chans,
+ sz/sizeof(u32));
+ if (ret < 0)
+ return ret;
+ }
+
+ prop = of_find_property(node, "ti,edma-reserved-slots", &sz);
+ if (prop) {
+ rsv_slots = devm_kzalloc(dev,
+ sz/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!rsv_slots)
+ return -ENOMEM;
+ pdata->rsv->rsv_slots = rsv_slots;
+
+ ret = edma_of_read_u32_to_s16_array(node,
+ "ti,edma-reserved-slots",
+ (s16 *)rsv_slots,
+ sz/sizeof(u32));
+ if (ret < 0)
+ return ret;
+ }
+
+ prop = of_find_property(node, "ti,edma-queue-tc-map", &sz);
+ if (!prop)
+ return -EINVAL;
+
+ queue_tc_map = devm_kzalloc(dev,
+ sz/sizeof(s8) + 2*sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+ pdata->queue_tc_mapping = queue_tc_map;
+
+ ret = edma_of_read_u32_to_s8_array(node,
+ "ti,edma-queue-tc-map",
+ (s8 *)queue_tc_map,
+ sz/sizeof(u32));
+ if (ret < 0)
+ return ret;
+
+ prop = of_find_property(node, "ti,edma-queue-priority-map", &sz);
+ if (!prop)
+ return -EINVAL;
+
+ queue_priority_map = devm_kzalloc(dev,
+ sz/sizeof(s8) + 2*sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+ pdata->queue_priority_mapping = queue_priority_map;
+
+ ret = edma_of_read_u32_to_s8_array(node,
+ "ti,edma-queue-tc-map",
+ (s8 *)queue_priority_map,
+ sz/sizeof(u32));
+ if (ret < 0)
+ return ret;
+
+ ret = of_property_read_u32(node, "ti,edma-default-queue", &value);
+ if (ret < 0)
+ return ret;
+ pdata->default_queue = value;
+
+ prop = of_find_property(node, "ti,edma-xbar-event-map", &sz);
+ if (prop)
+ ret = edma_xbar_event_map(dev, node, pdata, sz);
+
+ return ret;
+}
+
+static struct of_dma_filter_info edma_filter_info = {
+ .filter_fn = edma_filter_fn,
+};
static int edma_probe(struct platform_device *pdev)
{
struct edma_soc_info **info = pdev->dev.platform_data;
+ struct edma_soc_info *ninfo[EDMA_MAX_CC] = {NULL, NULL};
+ struct edma_soc_info tmpinfo;
const s8 (*queue_priority_mapping)[2];
const s8 (*queue_tc_mapping)[2];
int i, j, off, ln, found = 0;
int status = -1;
const s16 (*rsv_chans)[2];
const s16 (*rsv_slots)[2];
+ const s16 (*xbar_chans)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
- struct resource *r[EDMA_MAX_CC] = {NULL};
+ struct resource *r[EDMA_MAX_CC] = {NULL, NULL};
+ struct resource res[EDMA_MAX_CC];
resource_size_t len[EDMA_MAX_CC];
char res_name[10];
char irq_name[10];
+ struct device_node *node = pdev->dev.of_node;
+ struct device *dev = &pdev->dev;
+ int ret;
+
+ if (node) {
+ info = ninfo;
+ edma_of_parse_dt(dev, node, &tmpinfo);
+ info[0] = &tmpinfo;
+
+ dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+ of_dma_controller_register(dev->of_node,
+ of_dma_simple_xlate,
+ &edma_filter_info);
+ }
if (!info)
return -ENODEV;
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
+ if (IS_ERR_VALUE(ret)) {
+ dev_err(dev, "pm_runtime_get_sync() failed\n");
+ return ret;
+ }
+
for (j = 0; j < EDMA_MAX_CC; j++) {
- sprintf(res_name, "edma_cc%d", j);
- r[j] = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ if (!info[j]) {
+ if (!found)
+ return -ENODEV;
+ break;
+ }
+ if (node) {
+ ret = of_address_to_resource(node, j, &res[j]);
+ if (!IS_ERR_VALUE(ret))
+ r[j] = &res[j];
+ } else {
+ sprintf(res_name, "edma_cc%d", j);
+ r[j] = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM,
res_name);
- if (!r[j] || !info[j]) {
+ }
+ if (!r[j]) {
if (found)
break;
else
@@ -1465,8 +1735,22 @@ static int edma_probe(struct platform_device *pdev)
}
}
- sprintf(irq_name, "edma%d", j);
- irq[j] = platform_get_irq_byname(pdev, irq_name);
+ /* Clear the xbar mapped channels in unused list */
+ xbar_chans = info[j]->xbar_chans;
+ if (xbar_chans) {
+ for (i = 0; xbar_chans[i][1] != -1; i++) {
+ off = xbar_chans[i][1];
+ clear_bits(off, 1,
+ edma_cc[j]->edma_unused);
+ }
+ }
+
+ if (node)
+ irq[j] = irq_of_parse_and_map(node, 0);
+ else {
+ sprintf(irq_name, "edma%d", j);
+ irq[j] = platform_get_irq_byname(pdev, irq_name);
+ }
edma_cc[j]->irq_res_start = irq[j];
status = request_irq(irq[j], dma_irq_handler, 0, "edma",
&pdev->dev);
@@ -1476,8 +1760,12 @@ static int edma_probe(struct platform_device *pdev)
goto fail;
}
- sprintf(irq_name, "edma%d_err", j);
- err_irq[j] = platform_get_irq_byname(pdev, irq_name);
+ if (node)
+ err_irq[j] = irq_of_parse_and_map(node, 2);
+ else {
+ sprintf(irq_name, "edma%d_err", j);
+ err_irq[j] = platform_get_irq_byname(pdev, irq_name);
+ }
edma_cc[j]->irq_res_end = err_irq[j];
status = request_irq(err_irq[j], dma_ccerr_handler, 0,
"edma_error", &pdev->dev);
@@ -1538,9 +1826,17 @@ fail1:
return status;
}
+static const struct of_device_id edma_of_ids[] = {
+ { .compatible = "ti,edma3", },
+ {}
+};
static struct platform_driver edma_driver = {
- .driver.name = "edma",
+ .driver = {
+ .name = "edma",
+ .of_match_table = edma_of_ids,
+ },
+ .probe = edma_probe,
};
static int __init edma_init(void)
diff --git a/include/linux/platform_data/edma.h b/include/linux/platform_data/edma.h
index 2344ea2..ffc1fb2 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -177,6 +177,7 @@ struct edma_soc_info {
const s8 (*queue_tc_mapping)[2];
const s8 (*queue_priority_mapping)[2];
+ const s16 (*xbar_chans)[2];
};
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 04/14] dmaengine: edma: enable build for AM33XX
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Enable TI EDMA option on OMAP.
Signed-off-by: Matt Porter <mporter@ti.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d4c1218..20ef955 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -221,7 +221,7 @@ config SIRF_DMA
config TI_EDMA
tristate "TI EDMA support"
- depends on ARCH_DAVINCI
+ depends on ARCH_DAVINCI || ARCH_OMAP
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
default n
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 05/14] dmaengine: edma: Add TI EDMA device tree binding
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter <mporter@ti.com>
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49 +++++++++++++++++++++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 0000000..075a60e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : "ti,edma3"
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma at 49000000 {
+ reg = <0x49000000 0x10000>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-reserved-channels = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8>;
+ ti,edma-reserved-slots = <0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ ti,edma-xbar-event-map = <1 12
+ 2 13>;
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 06/14] ARM: dts: add AM33XX EDMA support
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter <mporter@ti.com>
---
arch/arm/boot/dts/am33xx.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..e711ffb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -87,6 +87,26 @@
reg = <0x48200000 0x1000>;
};
+ edma: edma at 49000000 {
+ compatible = "ti,edma3";
+ ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+ reg = <0x49000000 0x10000>,
+ <0x44e10f90 0x10>;
+ interrupt-parent = <&intc>;
+ interrupts = <12 13 14>;
+ #dma-cells = <1>;
+ dma-channels = <64>;
+ ti,edma-regions = <4>;
+ ti,edma-slots = <256>;
+ ti,edma-queue-tc-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-queue-priority-map = <0 0
+ 1 1
+ 2 2>;
+ ti,edma-default-queue = <0>;
+ };
+
gpio1: gpio at 44e07000 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio1";
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
include/linux/dmaengine.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9fd0c5b..64f9f69 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev->of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v5 08/14] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
From: Matt Porter @ 2013-01-15 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358281974-8411-1-git-send-email-mporter@ti.com>
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
---
drivers/mmc/host/omap_hsmmc.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bc58078..e79b12d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1915,14 +1915,20 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
+ host->rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ &rx_req, &pdev->dev, "rx");
+
if (!host->rx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
ret = -ENXIO;
goto err_irq;
}
- host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
+ host->tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+ &tx_req, &pdev->dev, "tx");
+
if (!host->tx_chan) {
dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
ret = -ENXIO;
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox