* [PATCH 6/6] ARM: OMAP2+: Move iommu/iovmm headers to platform_data
From: Tony Lindgren @ 2012-10-25 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025001913.2082.31062.stgit@muffinssi.local>
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Partially based on an earlier version by Ido Yariv <ido@wizery.com>.
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Ido Yariv <ido@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/omap-iommu.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
drivers/iommu/omap-iommu-debug.c | 3 +--
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/omap-iommu2.c | 2 +-
drivers/iommu/omap-iovmm.c | 3 +--
drivers/media/platform/omap3isp/ispvideo.c | 1 -
include/linux/platform_data/iommu-omap.h | 0
10 files changed, 8 insertions(+), 11 deletions(-)
rename arch/arm/plat-omap/include/plat/iommu.h => include/linux/platform_data/iommu-omap.h (100%)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index cba60e0..1002ff8 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
#if defined(CONFIG_IOMMU_API)
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
static struct resource omap3isp_resources[] = {
{
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..a6a4ff8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -13,7 +13,7 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include "soc.h"
#include "common.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..621bc71 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -26,8 +26,8 @@
#include <plat/mmc.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
+#include <linux/platform_data/iommu-omap.h>
#include <plat/dmtimer.h>
-#include <plat/iommu.h>
#include "am35xx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..5850b3e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -27,10 +27,10 @@
#include <plat/dma.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
+#include <linux/platform_data/iommu-omap.h>
#include <plat/mmc.h>
#include <plat/dmtimer.h>
#include <plat/common.h>
-#include <plat/iommu.h>
#include "omap_hwmod_common_data.h"
#include "cm1_44xx.h"
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index d0427bd..d97fbe4 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -19,8 +19,7 @@
#include <linux/platform_device.h>
#include <linux/debugfs.h>
#include <linux/omap-iommu.h>
-
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index df84087..badc17c 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,7 +26,7 @@
#include <asm/cacheflush.h>
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index 29e98a2..c020202 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -19,8 +19,8 @@
#include <linux/omap-iommu.h>
#include <linux/slab.h>
#include <linux/stringify.h>
+#include <linux/platform_data/iommu-omap.h>
-#include <plat/iommu.h>
#include "omap-iommu.h"
/*
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index 3e3b242..46d87569 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -18,12 +18,11 @@
#include <linux/scatterlist.h>
#include <linux/iommu.h>
#include <linux/omap-iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include <asm/cacheflush.h>
#include <asm/mach/map.h>
-#include <plat/iommu.h>
-
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/media/platform/omap3isp/ispvideo.c b/drivers/media/platform/omap3isp/ispvideo.c
index a4b8290..21f7313 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -35,7 +35,6 @@
#include <linux/vmalloc.h>
#include <media/v4l2-dev.h>
#include <media/v4l2-ioctl.h>
-#include <plat/iommu.h>
#include <plat/omap-pm.h>
#include "ispvideo.h"
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/include/linux/platform_data/iommu-omap.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/iommu.h
rename to include/linux/platform_data/iommu-omap.h
^ permalink raw reply related
* [PATCH 5/6] ARM: OMAP2+: Make some definitions local
From: Tony Lindgren @ 2012-10-25 0:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1467852.FtkNIyyq5l@avalon>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [121024 16:38]:
> On Wednesday 24 October 2012 16:33:18 Tony Lindgren wrote:
> >
> > BTW, after updating patch 3/6 I noticed patches 4 - 6 had trivial merge
> > conflicts with the includes, so let me know if you want met to repost the
> > whole set.
>
> Please do. I'll then ack it (provided I have no more comments to make of
> course :-)).
Posted now as "[PATCH v4 0/6] omap iommu changes to remove plat includes".
Also noticed one more sorting issue in the isp files that's fixed now.
Regards,
Tony
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-10-25 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2126833.cqGngBPXg2@avalon>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [121024 16:54]:
> On Wednesday 24 October 2012 15:34:12 Tony Lindgren wrote:
> >
> > BTW, doing a test compile on v3.7-rc2, I'm seeing the following warnings
> > for omap3isp for isp_video_ioctl_ops:
> >
> > drivers/media/platform/omap3isp/ispvideo.c:1213: warning: initialization
> > from incompatible pointer type
> > drivers/media/platform/omap3isp/ispccdc.c:2303: warning: initialization
> > from incompatible pointer type
> > drivers/media/platform/omap3isp/ispccdc.c:2304: warning: initialization
> > from incompatible pointer type
> > drivers/media/platform/omap3isp/isph3a_aewb.c:282: warning: initialization
> > from incompatible pointer type
> > drivers/media/platform/omap3isp/isph3a_aewb.c:283: warning: initialization
> > from incompatible pointer type
> > drivers/media/platform/omap3isp/isph3a_af.c:347: warning: initialization
> > from incompatible pointer type
> > drivers/media/platform/omap3isp/isph3a_af.c:348: warning: initialization
> > from incompatible pointer type
> > drivers/media/platform/omap3isp/isphist.c:453: warning: initialization from
> > incompatible pointer type
> > drivers/media/platform/omap3isp/isphist.c:454: warning: initialization from
> > incompatible pointer type
>
> I've just sent a pull request to linux-media for v3.7 with fixes for those.
OK thanks!
Tony
^ permalink raw reply
* [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
From: Tony Lindgren @ 2012-10-25 0:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507EB3CC.6060005@ti.com>
* Santosh Shilimkar <santosh.shilimkar@ti.com> [121017 06:35]:
> (Looping Arnd and Olof)
>
> On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:
> >When building omap_l3_noc/smx drivers as modules, the following
> >warning appears:
> >
> >CC [M] drivers/bus/omap_l3_smx.o
> >drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class
> >drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync'
> >drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration
> >drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
> >CC [M] drivers/bus/omap_l3_noc.o
> >drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class
> >drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync'
> >drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration
> >drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used
> >
> >Adding module_init() and macros in omap_l3_noc/smx drivers when building
> >as modules to remove the above warning.
> >
> >Reported-by: Tony Lindgren <tony@atomide.com>
> >Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> >---
> Thanks for the fix Lokesh. Looks fine to me.
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Looks like nobody else has picked this up so I'll queue this along
with few other omap warnings and regressions.
Regards,
Tony
^ permalink raw reply
* [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
From: Tony Lindgren @ 2012-10-25 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025003509.GI11928@atomide.com>
* Tony Lindgren <tony@atomide.com> [121024 17:36]:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [121017 06:35]:
> > (Looping Arnd and Olof)
> >
> > On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote:
> > >When building omap_l3_noc/smx drivers as modules, the following
> > >warning appears:
> > >
> > >CC [M] drivers/bus/omap_l3_smx.o
> > >drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class
> > >drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync'
> > >drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration
> > >drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used
> > >CC [M] drivers/bus/omap_l3_noc.o
> > >drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class
> > >drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync'
> > >drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration
> > >drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used
> > >
> > >Adding module_init() and macros in omap_l3_noc/smx drivers when building
> > >as modules to remove the above warning.
> > >
> > >Reported-by: Tony Lindgren <tony@atomide.com>
> > >Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> > >---
> > Thanks for the fix Lokesh. Looks fine to me.
> >
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> Looks like nobody else has picked this up so I'll queue this along
> with few other omap warnings and regressions.
Hmm actually this might require some more discussion. If we make
it use regular initcalls, then the ugly ifdefs can be left
out. Is there a reason to init this early, can't we just use regular
initcalls?
Dropping the patch for now anyways.
Regards,
Tony
^ permalink raw reply
* [PATCHv3] ARM: Sort exception table at compile time
From: Stephen Boyd @ 2012-10-25 0:44 UTC (permalink / raw)
To: linux-arm-kernel
Add the ARM machine identifier to sortextable and select the
config option so that we can sort the exception table at compile
time. sortextable relies on a section named __ex_table existing
in the vmlinux, but ARM's linker script places the exception
table in the data section. Give the exception table its own
section so that sortextable can find it.
This allows us to skip the sorting step during boot.
Cc: David Daney <david.daney@cavium.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Changes since v2:
* Refreshed against linux-next
arch/arm/Kconfig | 1 +
arch/arm/kernel/vmlinux.lds.S | 19 +++++++++----------
scripts/sortextable.c | 1 +
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 73067ef..208414c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -5,6 +5,7 @@ config ARM
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_WANT_IPC_PARSE_VERSION
+ select BUILDTIME_EXTABLE_SORT if MMU
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7) && !CPU_BIG_ENDIAN
select GENERIC_ATOMIC64 if (CPU_V6 || !CPU_32v6K || !AEABI)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 36ff15b..b9f38e3 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -114,6 +114,15 @@ SECTIONS
RO_DATA(PAGE_SIZE)
+ . = ALIGN(4);
+ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
+ __start___ex_table = .;
+#ifdef CONFIG_MMU
+ *(__ex_table)
+#endif
+ __stop___ex_table = .;
+ }
+
#ifdef CONFIG_ARM_UNWIND
/*
* Stack unwinding tables
@@ -220,16 +229,6 @@ SECTIONS
READ_MOSTLY_DATA(L1_CACHE_BYTES)
/*
- * The exception fixup table (might need resorting at runtime)
- */
- . = ALIGN(4);
- __start___ex_table = .;
-#ifdef CONFIG_MMU
- *(__ex_table)
-#endif
- __stop___ex_table = .;
-
- /*
* and the usual data section
*/
DATA_DATA
diff --git a/scripts/sortextable.c b/scripts/sortextable.c
index f19ddc4..1f10e89 100644
--- a/scripts/sortextable.c
+++ b/scripts/sortextable.c
@@ -248,6 +248,7 @@ do_file(char const *const fname)
case EM_S390:
custom_sort = sort_relative_table;
break;
+ case EM_ARM:
case EM_MIPS:
break;
} /* end switch */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
From: Tony Lindgren @ 2012-10-25 0:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016165043.GS15569@atomide.com>
* Tony Lindgren <tony@atomide.com> [121016 09:53]:
> * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > ocp2scp was not having pdata support which makes *musb* fail for non-dt
> > boot in OMAP platform. The pdata will have information about the devices
> > that is connected to ocp2scp. ocp2scp driver will now make use of this
> > information to create the devices that is attached to ocp2scp.
> >
> > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>
> This fixes the regression on my panda es for musb port:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Looks like nobody has picked this one up and we need it to
fix the musb regression on omap, so I'll queue these up.
Regards,
Tony
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Jon Hunter @ 2012-10-25 1:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350935758-9215-5-git-send-email-zonque@gmail.com>
Hi Daniel,
On 10/22/2012 02:55 PM, Daniel Mack wrote:
> This patch adds basic DT bindings for OMAP GPMC.
>
> The actual peripherals are instanciated from child nodes within the GPMC
> node, and the only type of device that is currently supported is NAND.
>
> Code was added to parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
>
> Successfully tested on an AM33xx board.
Thanks for sending this and sorry for the delay in responding. Some
comments below ...
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> Documentation/devicetree/bindings/bus/gpmc.txt | 59 +++++++++
> .../devicetree/bindings/mtd/gpmc-nand.txt | 65 ++++++++++
> arch/arm/mach-omap2/gpmc.c | 139 +++++++++++++++++++++
> 3 files changed, 263 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt b/Documentation/devicetree/bindings/bus/gpmc.txt
> new file mode 100644
> index 0000000..ef1c6e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/gpmc.txt
> @@ -0,0 +1,59 @@
> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
> +
> +The actual devices are instantiated from the child nodes of a GPMC node.
> +
> +Required properties:
> +
> + - compatible: Should be set to "ti,gpmc"
Is this the only required property? I think that "reg" and "ti,hwmods"
are probably also required.
Also given that we are describing the hardware, I am wondering if the
number of chip-selects and wait signals should be defined here too. I
recall that different devices had different number of wait pins available.
> +
> +Timing properties for child nodes. All are optional and default to 0.
> +
> + - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
> +
> + Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
> + - gpmc,cs-on: Assertion time
> + - gpmc,cs-rd-off: Read deassertion time
> + - gpmc,cs-wr-off: Write deassertion time
> +
> + ADV signal timings corresponding to GPMC_CONFIG3:
> + - gpmc,adv-on: Assertion time
> + - gpmc,adv-rd-off: Read deassertion time
> + - gpmc,adv-wr-off: Write deassertion time
> +
> + WE signals timings corresponding to GPMC_CONFIG4:
> + - gpmc,we-on: Assertion time
> + - gpmc,we-off: Deassertion time
> +
> + OE signals timings corresponding to GPMC_CONFIG4
> + - gpmc,oe-on: Assertion time
> + - gpmc,oe-off: Deassertion time
> +
> + Access time and cycle time timings corresponding to GPMC_CONFIG5
> + - gpmc,page-burst-access: Multiple access word delay
> + - gpmc,access: Start-cycle to first data valid delay
> + - gpmc,rd-cycle: Total read cycle time
> + - gpmc,wr-cycle: Total write cycle time
> +
> +The following are only on OMAP3430
> + - gpmc,wr-access
> + - gpmc,wr-data-mux-bus
> +
> +
> +Example for an AM33xx board:
> +
> + gpmc: gpmc at 50000000 {
> + compatible = "ti,gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x50000000 0x1000000>;
> + interrupt-parent = <&intc>;
> + interrupts = <100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* child nodes go here */
> + };
> +
> +
> +
> +
> +
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> new file mode 100644
> index 0000000..6790fcf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -0,0 +1,65 @@
> +Device tree bindings for GPMC connected NANDs
> +
> +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
> +the GPMC controller with a name of "nand".
> +
> +All timing relevant properties are explained in a separate documents - please
> +refer to Documentation/devicetree/bindings/bus/gpmc.txt
> +
> +Required properties:
> +
> + - reg: The CS line the peripheral is connected to
Is this the only required property? I would have thought that bus-width
is needed too.
In general, I am wondering if this should be broken into two patches as
you are creating the binding for the gpmc and nand here.
Cheers
Jon
^ permalink raw reply
* [PATCH v5 3/5] ARM: EXYNOS: Enable PMUs for exynos4
From: Chanho Park @ 2012-10-25 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMg5Nn5i=J8o3Rt8es3Tq_LZgVttuYSBbvYfmw1QTGwx0A@mail.gmail.com>
> -----Original Message-----
> From: Olof Johansson [mailto:olof at lixom.net]
> Sent: Thursday, October 25, 2012 2:15 AM
> To: Chanho Park
> Cc: kgene.kim at samsung.com; linux-samsung-soc at vger.kernel.org; linux-
> arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; ben-linux at fluff.org;
> kyungmin.park at samsung.com; sachin.kamat at linaro.org;
> thomas.abraham at linaro.org; will.deacon at arm.com
> Subject: Re: [PATCH v5 3/5] ARM: EXYNOS: Enable PMUs for exynos4
>
> Hi,
>
> On Tue, Oct 23, 2012 at 10:34 PM, Chanho Park
> <chanho61.park@samsung.com> wrote:
> > This patch defines irq numbers of ARM performance monitoring unit for
> exynos4.
> > Firs of all, we need to fix IRQ_PMU correctly and to split pmu
> > initialization of exynos from plat-samsung for easily defining it.
> >
> > The number of CPU cores and PMU irq numbers are vary according to soc
> types.
> > So, we need to identify each soc type using soc_is_xxx function and to
> > define the pmu irqs dynamically. For example, the exynos4412 has 4 cpu
> cores and pmus.
>
> I wonder if it's worth doing this complexity on the non-DT case for exynos4?
>
> I wish there was more focus on the Samsung platforms for getting the DT
> support up to par with non-DT so you can avoid having to add new platform
> devices like these in the first place.
The DT support of exynos4 is under development.
And many of exynos4 developers still use non-dt boot-up method.
By this time arm-pmu of exynos did not work. IMO we should fix and support it
for non-dt users.
Thanks,
Best regards,
Chanho Park
>
>
> Thanks,
>
> -Olof
^ permalink raw reply
* [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
From: Jon Hunter @ 2012-10-25 1:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350935758-9215-5-git-send-email-zonque@gmail.com>
On 10/22/2012 02:55 PM, Daniel Mack wrote:
> This patch adds basic DT bindings for OMAP GPMC.
>
> The actual peripherals are instanciated from child nodes within the GPMC
> node, and the only type of device that is currently supported is NAND.
>
> Code was added to parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
>
> Successfully tested on an AM33xx board.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> Documentation/devicetree/bindings/bus/gpmc.txt | 59 +++++++++
> .../devicetree/bindings/mtd/gpmc-nand.txt | 65 ++++++++++
> arch/arm/mach-omap2/gpmc.c | 139 +++++++++++++++++++++
> 3 files changed, 263 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt b/Documentation/devicetree/bindings/bus/gpmc.txt
> new file mode 100644
> index 0000000..ef1c6e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/gpmc.txt
> @@ -0,0 +1,59 @@
> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
> +
> +The actual devices are instantiated from the child nodes of a GPMC node.
> +
> +Required properties:
> +
> + - compatible: Should be set to "ti,gpmc"
> +
> +Timing properties for child nodes. All are optional and default to 0.
> +
> + - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
> +
> + Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
> + - gpmc,cs-on: Assertion time
> + - gpmc,cs-rd-off: Read deassertion time
> + - gpmc,cs-wr-off: Write deassertion time
> +
> + ADV signal timings corresponding to GPMC_CONFIG3:
> + - gpmc,adv-on: Assertion time
> + - gpmc,adv-rd-off: Read deassertion time
> + - gpmc,adv-wr-off: Write deassertion time
> +
> + WE signals timings corresponding to GPMC_CONFIG4:
> + - gpmc,we-on: Assertion time
> + - gpmc,we-off: Deassertion time
> +
> + OE signals timings corresponding to GPMC_CONFIG4
> + - gpmc,oe-on: Assertion time
> + - gpmc,oe-off: Deassertion time
> +
> + Access time and cycle time timings corresponding to GPMC_CONFIG5
> + - gpmc,page-burst-access: Multiple access word delay
> + - gpmc,access: Start-cycle to first data valid delay
> + - gpmc,rd-cycle: Total read cycle time
> + - gpmc,wr-cycle: Total write cycle time
> +
> +The following are only on OMAP3430
> + - gpmc,wr-access
> + - gpmc,wr-data-mux-bus
> +
> +
> +Example for an AM33xx board:
> +
> + gpmc: gpmc at 50000000 {
> + compatible = "ti,gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x50000000 0x1000000>;
Nit-pick, that size is quite large for a register range. I recommend
looking at the HWMOD data file
(arch/arm/mach-omap2/omap_hwmod_33xx_data.c) and see how much space is
allocated for the registers (see structure am33xx_gpmc_addr_space).
Cheers
Jon
^ permalink raw reply
* [PATCH v3] ARM: mach-imx: Fix selection of ARCH_MXC
From: Shawn Guo @ 2012-10-25 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121019150544.GD21078@S2101-09.ap.freescale.net>
On Fri, Oct 19, 2012 at 11:05:54PM +0800, Shawn Guo wrote:
> On Thu, Oct 18, 2012 at 03:04:30PM -0300, Fabio Estevam wrote:
> > Since commit c5a0d497(ARM: imx: enable multi-platform build),
> > ARCH_MXC is selected by the following logic:
> >
> > config ARCH_MXC
> > def_bool y if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
> >
> > , which causes build error on vexpress_defconfig:
> >
> > arch/arm/mach-imx/hotplug.c:49: undefined reference to `imx_enable_cpu'
> > arch/arm/mach-imx/platsmp.c:57: undefined reference to `imx_set_cpu_jump'
> > arch/arm/mach-imx/platsmp.c:58: undefined reference to `imx_enable_cpu'
> >
> > Make ARCH_MXC a user selectable option, so that it does not get built
> > by default on other defconfigs that select ARCH_MULTI_V4_V5 or ARCH_MULTI_V6_V7.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>
> Arnd, Olof,
>
> I just applied this patch on my imx/multi-platform. Can you please
> pull it to update the branch in arm-soc? Thanks.
>
I just applied another fix [1] on my branch. Please pull both into
arm-soc. Thanks.
Shawn
[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/195009
------
The following changes since commit c5a0d4977f00ca18c49d46fdaff4b2cfeaa4eb28:
ARM: imx: enable multi-platform build (2012-10-15 10:10:15 +0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform
for you to fetch changes up to 68b25325a7fd290b5e472bba0df9cbe8c1a81d8f:
ARM: imx: select HAVE_IMX_SRC when SMP is enabled (2012-10-23 15:37:51 +0800)
----------------------------------------------------------------
Fabio Estevam (1):
ARM: mach-imx: Fix selection of ARCH_MXC
Shawn Guo (1):
ARM: imx: select HAVE_IMX_SRC when SMP is enabled
arch/arm/configs/imx_v4_v5_defconfig | 1 +
arch/arm/configs/imx_v6_v7_defconfig | 1 +
arch/arm/mach-imx/Kconfig | 5 ++---
3 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: David Miller @ 2012-10-25 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351011300-26964-2-git-send-email-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Tue, 23 Oct 2012 18:54:57 +0200
> + u32 cause_rx_tx[CONFIG_NR_CPUS];
Please use per-cpu variables instead of explicitly sized
arrays.
^ permalink raw reply
* [PATCH 4/8] ARM: plat-nomadik: move DMA40 header to <linux/platform_data>
From: Vinod Koul @ 2012-10-25 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350580739-8446-1-git-send-email-linus.walleij@stericsson.com>
On Thu, 2012-10-18 at 19:18 +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This moves the DMA40 platform data header from <plat/ste_dma40.h>
> to <linux/platform_data/dma-ste-dma40.h> where is belongs.
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH 2/2] cpufreq: governors: remove redundant code
From: Viresh Kumar @ 2012-10-25 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3245066.cWfgP9Ikey@vostro.rjw.lan>
On 25 October 2012 02:42, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday 24 of October 2012 21:43:46 Rafael J. Wysocki wrote:
>> On Wednesday 24 of October 2012 11:37:13 Viresh Kumar wrote:
>> > On 22 October 2012 14:16, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> > > On 20 October 2012 01:42, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> > >> Initially ondemand governor was written and then using its code conservative
>> > >> governor is written. It used a lot of code from ondemand governor, but copy of
>> > >> code was created instead of using the same routines from both governors. Which
>> > >> increased code redundancy, which is difficult to manage.
>> > >>
>> > >> This patch is an attempt to move common part of both the governors to
>> > >> cpufreq_governor.c file to come over above mentioned issues.
>> > >>
>> > >> This shouldn't change anything from functionality point of view.
>> > >>
>> > >> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> >
>> > For everybody else, this patch is already pushed by Rafael in his linux-next
>> > branch.
>>
>> Well, not yet, although I'm going to do that.
>
> Or I would if it still applied. Unfortunately, though, it doesn't apply any
> more to my linux-next branch due to some previous changes in it.
>
> Care to rebase?
Ahh.. I got confused by the following patch:
commit 83a73f712f2275033b2dc7f5c664988a1823ebc7
Author: viresh kumar <viresh.kumar@linaro.org>
Date: Tue Oct 23 01:28:05 2012 +0200
cpufreq: Move common part from governors to separate file, v2
Multiple cpufreq governers have defined similar get_cpu_idle_time_***()
routines. These routines must be moved to some common place, so that all
governors can use them.
So moving them to cpufreq_governor.c, which seems to be a better place for
keeping these routines.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Actually, i should i have replied on this patch (and i forgot). I
wanted you to skip
this patch, as the latest patch already had this change.
But now i see commits from others on cpufreq_governor.c file.
Hmm... So you can keep your tree as it is and apply the attached
patch. It is the
same patch getting discussed in this thread. Just rebased over your latest next.
You must also apply my other patches fixing sparse warnings (they can be applied
over this patch, tested), to fix sparse warnings from cpufreq.
--
viresh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cpufreq-governors-remove-redundant-code.patch
Type: application/octet-stream
Size: 67140 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121025/7b6d8c31/attachment-0001.obj>
^ permalink raw reply
* [PATCH v2 2/3] serial: mxs-auart: add the DMA support for mx28
From: Vinod Koul @ 2012-10-25 4:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351074456-25863-3-git-send-email-b32955@freescale.com>
On Wed, 2012-10-24 at 18:27 +0800, Huang Shijie wrote:
> Only we meet the following conditions, we can enable the DMA support for
> auart:
>
> (1) We enable the DMA support in the dts file, such as
> arch/arm/boot/dts/imx28.dtsi.
>
> (2) We enable the hardware flow control.
>
> (3) We use the mx28, not the mx23. Due to hardware bug(see errata: 2836),
> we can not add the DMA support to mx23.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
>
> #define to_auart_port(u) container_of(u, struct mxs_auart_port, port)
> +
> +static int mxs_auart_dma_tx(struct mxs_auart_port *s, int size)
> +{
> + struct dma_async_tx_descriptor *desc;
> + struct scatterlist *sgl = &s->tx_sgl;
> + struct dma_chan *channel = s->tx_dma_chan;
> + u32 pio;
> +
> + /* [1] : send PIO. Note, the first pio word is CTRL1. */
> + pio = AUART_CTRL1_XFER_COUNT(size);
> + desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)&pio,
> + 1, DMA_TRANS_NONE, 0);
this seems like a hack. API expects a scatterlist as argument.
Same thing about direction, NONE doesnt mean anything for dma transfer.
> + if (!desc) {
> + dev_err(s->dev, "step 1 error\n");
> + return -EINVAL;
> + }
> +
> + /* [2] : set DMA buffer. */
> + sg_init_one(sgl, s->tx_dma_buf, size);
> + dma_map_sg(s->dev, sgl, 1, DMA_TO_DEVICE);
> + desc = dmaengine_prep_slave_sg(channel, sgl,
> + 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (!desc) {
> + dev_err(s->dev, "step 2 error\n");
> + return -EINVAL;
> + }
> +
> + /* [3] : submit the DMA */
> + desc->callback = dma_tx_callback;
> + desc->callback_param = s;
> + dmaengine_submit(desc);
> + dma_async_issue_pending(channel);
> + return 0;
> +}
> +
>
> +static bool mxs_auart_dma_filter(struct dma_chan *chan, void *param)
> +{
> + struct mxs_auart_port *s = param;
> +
> + if (!mxs_dma_is_apbx(chan))
> + return false;
> +
> + if (s->dma_channel == chan->chan_id) {
> + chan->private = &s->dma_data;
dont use chan->private. You need to dmaengine_slave_config API
> + return true;
> + }
> + return false;
> +}
> +
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH 3/3] dmaengine: sirf: enable the driver support new SiRFmarco SoC
From: Vinod Koul @ 2012-10-25 4:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4yY6YYKb+g4k7BcL_SyyBN9xYCwxRLX6rN5_afroK0e_g@mail.gmail.com>
On Wed, 2012-10-24 at 19:59 +0800, Barry Song wrote:
> Hi Vinod,
> Thanks a lot!
Please dont top post.
>
> 2012/10/24 Vinod Koul <vkoul@infradead.org>
> >
> > On Thu, 2012-09-27 at 16:36 +0800, Barry Song wrote:
> > > From: Barry Song <Baohua.Song@csr.com>
> > >
> > > The driver supports old up SiRFprimaII SoCs, this patch makes it support
> > > the new SiRFmarco as well.
> > > SiRFmarco, as a SMP SoC, adds new DMA_INT_EN_CLR and DMA_CH_LOOP_CTRL_CLR
> > > registers, to disable IRQ/Channel, we should write 1 to the corresponding
> > > bit in the two CLEAR register.
> > >
> > > Tested on SiRFmarco using SPI driver:
> > > $ /mnt/spidev-sirftest -D /dev/spidev32766.0
> > > spi mode: 0
> > > bits per word: 8
> > > max speed: 500000 Hz (500 KHz)
> > >
> > > 00 00 00 00 00 00
> > > 00 00 00 00 00 00
> > > 00 00 00 00 00 00
> > > 00 00 00 00 00 00
> > > 00 00 00 00 00 00
> > > 00 00 00 00 00 00
> > > 00 00 00 00
> > >
> > > $ cat /proc/interrupts
> > > CPU0 CPU1
> > > 32: 1593 0 GIC sirfsoc_timer0
> > > 33: 0 3533 GIC sirfsoc_timer1
> > > 44: 0 0 GIC sirfsoc_dma
> > > 45: 16 0 GIC sirfsoc_dma
> > > 47: 6 0 GIC sirfsoc_spi
> > > 50: 5654 0 GIC sirfsoc-uart
> > > ...
> > >
> > > Signed-off-by: Barry Song <Baohua.Song@csr.com>
> > > ---
I tried applying this and it failed for me. Can you please respin this
on my next and send again.
--
Vinod Koul
Intel Corp.
^ permalink raw reply
* [PATCH v2] ARM: add back in KS8695 based SnapGear board entries
From: gerg at snapgear.com @ 2012-10-25 5:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Greg Ungerer <gerg@uclinux.org>
As of linux-3.7-rc1 configuring to build for the Micrel KS8695 based
SnapGear board types will result in a build failure:
CC arch/arm/mach-ks8695/board-sg.o
arch/arm/mach-ks8695/board-sg.c:88: error: ?MACH_TYPE_LITE300? undeclared here (not in a function)
arch/arm/mach-ks8695/board-sg.c:100: error: ?MACH_TYPE_SG310? undeclared here (not in a function)
arch/arm/mach-ks8695/board-sg.c:112: error: ?MACH_TYPE_SE4200? undeclared here (not in a function)
Add the removed SnapGear board IDs back into the mach-types file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
v2: update commit log to reflect actual compile error now
arch/arm/tools/mach-types | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index 831e1fd..df1aefb 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -95,6 +95,7 @@ lpd7a400 MACH_LPD7A400 LPD7A400 389
lpd7a404 MACH_LPD7A404 LPD7A404 390
csb337 MACH_CSB337 CSB337 399
mainstone MACH_MAINSTONE MAINSTONE 406
+lite300 MACH_LITE300 LITE300 408
xcep MACH_XCEP XCEP 413
arcom_vulcan MACH_ARCOM_VULCAN ARCOM_VULCAN 414
nomadik MACH_NOMADIK NOMADIK 420
@@ -160,6 +161,7 @@ trizeps4 MACH_TRIZEPS4 TRIZEPS4 776
cpuat91 MACH_CPUAT91 CPUAT91 787
iq81340sc MACH_IQ81340SC IQ81340SC 799
iq81340mc MACH_IQ81340MC IQ81340MC 801
+se4200 MACH_SE4200 SE4200 809
micro9 MACH_MICRO9 MICRO9 811
micro9l MACH_MICRO9L MICRO9L 812
omap_palmte MACH_OMAP_PALMTE OMAP_PALMTE 817
@@ -268,6 +270,7 @@ dns323 MACH_DNS323 DNS323 1542
omap3_beagle MACH_OMAP3_BEAGLE OMAP3_BEAGLE 1546
nokia_n810 MACH_NOKIA_N810 NOKIA_N810 1548
pcm038 MACH_PCM038 PCM038 1551
+sg310 MACH_SG310 SG310 1564
ts209 MACH_TS209 TS209 1565
at91cap9adk MACH_AT91CAP9ADK AT91CAP9ADK 1566
mx31moboard MACH_MX31MOBOARD MX31MOBOARD 1574
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2] ARM: add back in KS8695 based OpenGear board entries
From: gerg at snapgear.com @ 2012-10-25 5:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Greg Ungerer <gerg@uclinux.org>
As of linux-3.7-rc1 configuring to build for the Micrel KS8695 based
OpenGear board types will result in a build failure:
CC arch/arm/mach-ks8695/board-og.o
arch/arm/mach-ks8695/board-og.c:142: error: ?MACH_TYPE_CM4002? undeclared here (not in a function)
arch/arm/mach-ks8695/board-og.c:154: error: ?MACH_TYPE_CM4008? undeclared here (not in a function)
arch/arm/mach-ks8695/board-og.c:166: error: ?MACH_TYPE_CM41XX? undeclared here (not in a function)
arch/arm/mach-ks8695/board-og.c:178: error: ?MACH_TYPE_IM4004? undeclared here (not in a function)
arch/arm/mach-ks8695/board-og.c:190: error: ?MACH_TYPE_IM42XX? undeclared here (not in a function)
Add the removed OpenGear board IDs back into the mach-types file.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
v2: update commit log to reflect actual compile error now
arch/arm/tools/mach-types | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index df1aefb..d5f2fe5 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -132,12 +132,14 @@ kb9200 MACH_KB9200 KB9200 612
sx1 MACH_SX1 SX1 613
ixdp465 MACH_IXDP465 IXDP465 618
ixdp2351 MACH_IXDP2351 IXDP2351 619
+cm4008 MACH_CM4008 CM4008 624
iq80332 MACH_IQ80332 IQ80332 629
gtwx5715 MACH_GTWX5715 GTWX5715 641
csb637 MACH_CSB637 CSB637 648
n30 MACH_N30 N30 656
nec_mp900 MACH_NEC_MP900 NEC_MP900 659
kafa MACH_KAFA KAFA 662
+cm41xx MACH_CM41XX CM41XX 672
ts72xx MACH_TS72XX TS72XX 673
otom MACH_OTOM OTOM 680
nexcoder_2440 MACH_NEXCODER_2440 NEXCODER_2440 681
@@ -180,6 +182,7 @@ mx21ads MACH_MX21ADS MX21ADS 851
ams_delta MACH_AMS_DELTA AMS_DELTA 862
nas100d MACH_NAS100D NAS100D 865
magician MACH_MAGICIAN MAGICIAN 875
+cm4002 MACH_CM4002 CM4002 876
nxdkn MACH_NXDKN NXDKN 880
palmtx MACH_PALMTX PALMTX 885
s3c2413 MACH_S3C2413 S3C2413 887
@@ -216,6 +219,7 @@ fsg MACH_FSG FSG 1091
at91sam9260ek MACH_AT91SAM9260EK AT91SAM9260EK 1099
glantank MACH_GLANTANK GLANTANK 1100
n2100 MACH_N2100 N2100 1101
+im42xx MACH_IM42XX IM42XX 1105
qt2410 MACH_QT2410 QT2410 1108
kixrp435 MACH_KIXRP435 KIXRP435 1109
cc9p9360dev MACH_CC9P9360DEV CC9P9360DEV 1114
@@ -249,6 +253,7 @@ csb726 MACH_CSB726 CSB726 1359
davinci_dm6467_evm MACH_DAVINCI_DM6467_EVM DAVINCI_DM6467_EVM 1380
davinci_dm355_evm MACH_DAVINCI_DM355_EVM DAVINCI_DM355_EVM 1381
littleton MACH_LITTLETON LITTLETON 1388
+im4004 MACH_IM4004 IM4004 1400
realview_pb11mp MACH_REALVIEW_PB11MP REALVIEW_PB11MP 1407
mx27_3ds MACH_MX27_3DS MX27_3DS 1430
halibut MACH_HALIBUT HALIBUT 1439
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/3] dmaengine: sirf: enable the driver support new SiRFmarco SoC
From: Barry Song @ 2012-10-25 5:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351138901.5263.70.camel@vkoul-udesk3>
2012/10/25 Vinod Koul <vkoul@infradead.org>:
> On Wed, 2012-10-24 at 19:59 +0800, Barry Song wrote:
>> Hi Vinod,
>> Thanks a lot!
> Please dont top post.
well. saying hello is an exception :-)
>>
>> 2012/10/24 Vinod Koul <vkoul@infradead.org>
>> >
>> > On Thu, 2012-09-27 at 16:36 +0800, Barry Song wrote:
>> > > From: Barry Song <Baohua.Song@csr.com>
>> > >
>> > > The driver supports old up SiRFprimaII SoCs, this patch makes it support
>> > > the new SiRFmarco as well.
>> > > SiRFmarco, as a SMP SoC, adds new DMA_INT_EN_CLR and DMA_CH_LOOP_CTRL_CLR
>> > > registers, to disable IRQ/Channel, we should write 1 to the corresponding
>> > > bit in the two CLEAR register.
>> > >
>> > > Tested on SiRFmarco using SPI driver:
>> > > $ /mnt/spidev-sirftest -D /dev/spidev32766.0
>> > > spi mode: 0
>> > > bits per word: 8
>> > > max speed: 500000 Hz (500 KHz)
>> > >
>> > > 00 00 00 00 00 00
>> > > 00 00 00 00 00 00
>> > > 00 00 00 00 00 00
>> > > 00 00 00 00 00 00
>> > > 00 00 00 00 00 00
>> > > 00 00 00 00 00 00
>> > > 00 00 00 00
>> > >
>> > > $ cat /proc/interrupts
>> > > CPU0 CPU1
>> > > 32: 1593 0 GIC sirfsoc_timer0
>> > > 33: 0 3533 GIC sirfsoc_timer1
>> > > 44: 0 0 GIC sirfsoc_dma
>> > > 45: 16 0 GIC sirfsoc_dma
>> > > 47: 6 0 GIC sirfsoc_spi
>> > > 50: 5654 0 GIC sirfsoc-uart
>> > > ...
>> > >
>> > > Signed-off-by: Barry Song <Baohua.Song@csr.com>
>> > > ---
> I tried applying this and it failed for me. Can you please respin this
> on my next and send again.
ok
>
> --
> Vinod Koul
> Intel Corp.
-barry
^ permalink raw reply
* [PATCH 1/2] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Marek Szyprowski @ 2012-10-25 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351086561-13569-2-git-send-email-gregory.clement@free-electrons.com>
Hello,
On 10/24/2012 3:49 PM, Gregory CLEMENT wrote:
> For Armada 370/XP we have the same problem that for the commit
> cb01b63, so we applied the same solution: "The default 256 KiB
> coherent pool may be too small for some of the Kirkwood devices, so
> increase it to make sure that devices will be able to allocate their
> buffers with GFP_ATOMIC flag"
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mach-mvebu/armada-370-xp.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
> index 2af6ce5..cbad821 100644
> --- a/arch/arm/mach-mvebu/armada-370-xp.c
> +++ b/arch/arm/mach-mvebu/armada-370-xp.c
> @@ -17,6 +17,7 @@
> #include <linux/of_platform.h>
> #include <linux/io.h>
> #include <linux/time-armada-370-xp.h>
> +#include <linux/dma-mapping.h>
> #include <asm/mach/arch.h>
> #include <asm/mach/map.h>
> #include <asm/mach/time.h>
> @@ -43,6 +44,16 @@ void __init armada_370_xp_timer_and_clk_init(void)
> armada_370_xp_timer_init();
> }
>
> +void __init armada_370_xp_init_early(void)
> +{
> + /*
> + * Some Armada 370/XP devices allocate their coherent buffers
> + * from atomic context. Increase size of atomic coherent pool
> + * to make sure such the allocations won't fail.
> + */
> + init_dma_coherent_pool_size(SZ_1M);
> +}
> +
> struct sys_timer armada_370_xp_timer = {
> .init = armada_370_xp_timer_and_clk_init,
> };
> @@ -61,6 +72,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
> DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
> .init_machine = armada_370_xp_dt_init,
> .map_io = armada_370_xp_map_io,
> + .init_early = armada_370_xp_init_early,
> .init_irq = armada_370_xp_init_irq,
> .handle_irq = armada_370_xp_handle_irq,
> .timer = &armada_370_xp_timer,
>
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti @ 2012-10-25 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023191124.GB853@arwen.pp.htv.fi>
On 10/24/2012 12:41 AM, Felipe Balbi wrote:
>>
>> > return 0;
>> > }
> another thing, the few places in omap_i2c_xfer_msg() which are currently
> calling omap_i2c_init() should also be converted to call the newly added
> __omap_i2c_init(). We don't need to recalculate any of those clock
> dividers and whatnot.
Yes in fact omap_i2c_init() can be reset - calculate - and __omap_i2c_init.
Then in those places the recalculate can be optimised.
^ permalink raw reply
* [GIT PULL] CMA and DMA-mapping fixes for v3.7-rc3
From: Marek Szyprowski @ 2012-10-25 5:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
I would like to ask for pulling some minor fixes for both CMA
(Contiguous Memory Allocator) and DMA-mapping framework for v3.7-rc3.
----------------------------------------------------------------
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git fixes_for_linus
for you to fetch changes up to 4e85fb831aa210fd1c5e2cb7909ac203c1f5b67f:
ARM: mm: Remove unused arm_vmregion priv field (2012-10-24 07:38:15 +0200)
----------------------------------------------------------------
This pull request consists mainly of a set of one-liner fixes and
cleanups for a few minor issues identified in both Contiguous Memory
Allocator code and ARM DMA-mapping subsystem.
Thanks!
Best regards
Marek Szyprowski
Samsung Poland R&D Center
----------------------------------------------------------------
Patch summary:
Bob Liu (1):
mm: cma: alloc_contig_range: return early for err path
Jingoo Han (1):
ARM: dma-mapping: fix build warning in __dma_alloc()
Laurent Pinchart (4):
drivers: dma-contiguous: Don't redefine SZ_1M
drivers: dma-coherent: Fix typo in dma_mmap_from_coherent documentation
drivers: cma: Fix wrong CMA selected region size default value
ARM: mm: Remove unused arm_vmregion priv field
Ming Lei (1):
ARM: dma-mapping: support debug_dma_mapping_error
arch/arm/include/asm/dma-mapping.h | 1 +
arch/arm/mm/dma-mapping.c | 2 +-
arch/arm/mm/vmregion.h | 1 -
drivers/base/Kconfig | 2 +-
drivers/base/dma-coherent.c | 5 ++---
drivers/base/dma-contiguous.c | 5 +----
mm/page_alloc.c | 2 +-
7 files changed, 7 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Andrew Lunn @ 2012-10-25 5:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121024233356.1bda95bf@skate>
On Wed, Oct 24, 2012 at 11:33:56PM +0200, Thomas Petazzoni wrote:
> Andrew,
>
> On Wed, 24 Oct 2012 22:01:28 +0200, Andrew Lunn wrote:
>
> > I guess it is too early to use gpio. I don't think the gpio driver has
> > not been configured yet.
> >
> > I need to think about this.
> >
> > What happens if you comment out these two gpio_set_value calls?
>
> The problem is (probably, I haven't tested) that in
> mach-kirkwood/board-dt.c, the of_platform_populate() function is called
> after all the board-specific init. So all the devices described in the
> DT, including GPIO banks, have not been registered yet. Most likely the
> of_platform_populate() should come before the board specific inits.
Thanks Thomas, i will play around with this.
I'm just wondering if we are going to get into ordering issues. These
gpio operations are providing power to subsystems. We probably need
that to happen before the driver is loaded. If we call
of_platform_populate() too early, do we have the danger the driver
probing is going to happen before the init routine can enable the
power?
It seems like we want pinctrl/gpio working first, with pins hogged as
specified in DT, then the board init() function, then the rest of DT
setup.
> Also there should probably be a gpio_request() before those
> gpio_set_value().
Yes. That worked before, but might break now. Most of the init()
functions do actually make a gpip_request() call.
Andrew
^ permalink raw reply
* [PATCH v2 2/3] serial: mxs-auart: add the DMA support for mx28
From: Huang Shijie @ 2012-10-25 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351138689.5263.68.camel@vkoul-udesk3>
? 2012?10?25? 12:18, Vinod Koul ??:
>
>> +
>> +static int mxs_auart_dma_tx(struct mxs_auart_port *s, int size)
>> +{
>> + struct dma_async_tx_descriptor *desc;
>> + struct scatterlist *sgl =&s->tx_sgl;
>> + struct dma_chan *channel = s->tx_dma_chan;
>> + u32 pio;
>> +
>> + /* [1] : send PIO. Note, the first pio word is CTRL1. */
>> + pio = AUART_CTRL1_XFER_COUNT(size);
>> + desc = dmaengine_prep_slave_sg(channel, (struct scatterlist *)&pio,
>> + 1, DMA_TRANS_NONE, 0);
> this seems like a hack. API expects a scatterlist as argument.
> Same thing about direction, NONE doesnt mean anything for dma transfer.
It's not a hack. this DMA descriptor is used to set the registers.
Please see the code in drivers/dma/mxs-dma.c:mxs_dam_prep_slave_sg().
>> + if (!desc) {
>> + dev_err(s->dev, "step 1 error\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* [2] : set DMA buffer. */
>> + sg_init_one(sgl, s->tx_dma_buf, size);
>> + dma_map_sg(s->dev, sgl, 1, DMA_TO_DEVICE);
>> + desc = dmaengine_prep_slave_sg(channel, sgl,
>> + 1, DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
>> + if (!desc) {
>> + dev_err(s->dev, "step 2 error\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* [3] : submit the DMA */
>> + desc->callback = dma_tx_callback;
>> + desc->callback_param = s;
>> + dmaengine_submit(desc);
>> + dma_async_issue_pending(channel);
>> + return 0;
>> +}
>> +
>>
>> +static bool mxs_auart_dma_filter(struct dma_chan *chan, void *param)
>> +{
>> + struct mxs_auart_port *s = param;
>> +
>> + if (!mxs_dma_is_apbx(chan))
>> + return false;
>> +
>> + if (s->dma_channel == chan->chan_id) {
>> + chan->private =&s->dma_data;
> dont use chan->private. You need to dmaengine_slave_config API
please see the drivers/dma/mxs-dma.c:mxs_dam_alloc_chan_resoures().
The mxs-dma driver uses ->private to store the channel interrupt number.
thanks
Huang Shijie
>> + return true;
>> + }
>> + return false;
>> +}
>> +
^ permalink raw reply
* [PATCH] i2c: omap: re-factor omap_i2c_init function
From: Shubhrajyoti Datta @ 2012-10-25 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121023175706.GC32517@arwen.pp.htv.fi>
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
>> >> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
>> >> {
>> >> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>> >>
>> >> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> >> - }
>> >> -
>> >> - /*
>> >> - * Don't write to this register if the IE state is 0 as it can
>> >> - * cause deadlock.
>> >> - */
>> >> - if (_dev->iestate)
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
>> >
>> > this part is not on __omap_i2c_init() so you're potentially causing a
>> > regression here.
>>
>> iestate is set at init so cannot be zero. so the check was removed.
>
Hmm thinking a little more, there is a case that I missed the resume
handler may get called before
the omap_i2c_init will restore the check and send another version.
^ permalink raw reply
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