* [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: James Bottomley @ 2013-01-17 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116231401.GV23505@n2100.arm.linux.org.uk>
On Wed, 2013-01-16 at 23:14 +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 16, 2013 at 10:32:35AM +0000, James Bottomley wrote:
> > On Wed, 2013-01-16 at 12:07 +0530, Subhash Jadavani wrote:
> >
> > > Now consider this call stack from MMC block driver (this is on the ARmv7
> > > based board):
> > > [ 98.918174] [<c001b50c>] (v7_dma_inv_range+0x30/0x48) from
> > > [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c)
> > > [ 98.927819] [<c0017b8c>] (dma_cache_maint_page+0x1c4/0x24c) from
> > > [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c)
> > > [ 98.937982] [<c0017c28>] (___dma_page_cpu_to_dev+0x14/0x1c) from
> > > [<c0017ff8>] (dma_map_sg+0x3c/0x114)
> >
> > OK, so this is showing that ARM itself is making the assumption that the
> > pages are contiguous in the page offset map.
> >
> > Fix this by doing the increment via the pfn, which will do the right
> > thing whatever the memory model.
> >
> > Signed-off-by: James Bottomley <JBottomley@Parallels.com>
>
> Ok. What would you like the patch summary line for this to be -
> the existing one seems to be a little wrong given the content of
> this patch...
how about
arm: fix struct page iterator in dma_cache_maint() to work with
sparsemem
?
James
> >
> > ---
> >
> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > index 6b2fb87..ab88c5b 100644
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -809,7 +809,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
> > op(vaddr, len, dir);
> > }
> > offset = 0;
> > - page++;
> > + page = pfn_to_page(page_to_pfn(page) + 1);
> > left -= len;
> > } while (left);
> > }
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: imx: use debug_ll_io_init() for imx6q
From: Shawn Guo @ 2013-01-17 8:39 UTC (permalink / raw)
To: linux-arm-kernel
Use debug_ll_io_init() to map low level debug port for imx6q, so that
arch/arm/mach-imx/lluart.c can be removed.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/mach-imx/Makefile | 1 -
arch/arm/mach-imx/common.h | 5 -----
arch/arm/mach-imx/lluart.c | 47 ----------------------------------------
arch/arm/mach-imx/mach-imx6q.c | 3 ++-
4 files changed, 2 insertions(+), 54 deletions(-)
delete mode 100644 arch/arm/mach-imx/lluart.c
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 0634b31..f35eb39 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -88,7 +88,6 @@ obj-$(CONFIG_MACH_EUKREA_CPUIMX35SD) += mach-cpuimx35.o
obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd35-baseboard.o
obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
-obj-$(CONFIG_DEBUG_LL) += lluart.o
obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
obj-$(CONFIG_HAVE_IMX_SRC) += src.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 7eb3bb2..d672640 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -116,11 +116,6 @@ void tzic_handle_irq(struct pt_regs *);
extern void imx_enable_cpu(int cpu, bool enable);
extern void imx_set_cpu_jump(int cpu, void *jump_addr);
-#ifdef CONFIG_DEBUG_LL
-extern void imx_lluart_map_io(void);
-#else
-static inline void imx_lluart_map_io(void) {}
-#endif
extern void v7_cpu_resume(void);
extern u32 *pl310_get_save_ptr(void);
#ifdef CONFIG_SMP
diff --git a/arch/arm/mach-imx/lluart.c b/arch/arm/mach-imx/lluart.c
deleted file mode 100644
index 2fdc9bf..0000000
--- a/arch/arm/mach-imx/lluart.c
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * Copyright 2011 Freescale Semiconductor, Inc.
- * Copyright 2011 Linaro Ltd.
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-#include <linux/init.h>
-#include <asm/page.h>
-#include <asm/sizes.h>
-#include <asm/mach/map.h>
-
-#include "hardware.h"
-
-#define IMX6Q_UART1_BASE_ADDR 0x02020000
-#define IMX6Q_UART2_BASE_ADDR 0x021e8000
-#define IMX6Q_UART3_BASE_ADDR 0x021ec000
-#define IMX6Q_UART4_BASE_ADDR 0x021f0000
-#define IMX6Q_UART5_BASE_ADDR 0x021f4000
-
-/*
- * IMX6Q_UART_BASE_ADDR is put in the middle to force the expansion
- * of IMX6Q_UART##n##_BASE_ADDR.
- */
-#define IMX6Q_UART_BASE_ADDR(n) IMX6Q_UART##n##_BASE_ADDR
-#define IMX6Q_UART_BASE(n) IMX6Q_UART_BASE_ADDR(n)
-#define IMX6Q_DEBUG_UART_BASE IMX6Q_UART_BASE(CONFIG_DEBUG_IMX6Q_UART_PORT)
-
-static struct map_desc imx_lluart_desc = {
-#ifdef CONFIG_DEBUG_IMX6Q_UART
- .virtual = IMX_IO_P2V(IMX6Q_DEBUG_UART_BASE),
- .pfn = __phys_to_pfn(IMX6Q_DEBUG_UART_BASE),
- .length = 0x4000,
- .type = MT_DEVICE,
-#endif
-};
-
-void __init imx_lluart_map_io(void)
-{
- if (imx_lluart_desc.virtual)
- iotable_init(&imx_lluart_desc, 1);
-}
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index a009df7..ce7476d 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -31,6 +31,7 @@
#include <asm/hardware/cache-l2x0.h>
#include <asm/hardware/gic.h>
#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
#include <asm/mach/time.h>
#include <asm/system_misc.h>
@@ -216,7 +217,7 @@ static void __init imx6q_init_late(void)
static void __init imx6q_map_io(void)
{
- imx_lluart_map_io();
+ debug_ll_io_init();
imx_scu_map_io();
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: spear3xx: Fix pl080-related build failure
From: Viresh Kumar @ 2013-01-17 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358411351-18506-1-git-send-email-thierry.reding@avionic-design.de>
On Thu, Jan 17, 2013 at 1:59 PM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> Include linux/amba/pl08x.h to pull in the various PL080_* macros.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---
> arch/arm/mach-spear3xx/spear3xx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-spear3xx/spear3xx.c b/arch/arm/mach-spear3xx/spear3xx.c
> index f9d754f..7c218d9 100644
> --- a/arch/arm/mach-spear3xx/spear3xx.c
> +++ b/arch/arm/mach-spear3xx/spear3xx.c
> @@ -14,6 +14,7 @@
> #define pr_fmt(fmt) "SPEAr3xx: " fmt
>
> #include <linux/amba/pl022.h>
> +#include <linux/amba/pl080.h>
> #include <linux/amba/pl08x.h>
> #include <linux/io.h>
> #include <plat/pl080.h>
Hi Thierry,
Thanks for fixing it up. Though the log doesn't match the change well.
^ permalink raw reply
* [PATCH 3/3] ARM: omap2: use get_auxcr for aux ctrl register read
From: Santosh Shilimkar @ 2013-01-17 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358391205-23943-3-git-send-email-robherring2@gmail.com>
On Thursday 17 January 2013 08:23 AM, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Use get_auxcr instead of inline assembly to read the CP15 aux ctrl
> register.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
This patch and the rest of the series looks fine to me.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH] ARM: imx: remove unused imx6q_clock_map_io()
From: Shawn Guo @ 2013-01-17 8:29 UTC (permalink / raw)
To: linux-arm-kernel
imx6q_clock_map_io() becomes an empty function since imx6q clock driver
is moved to common clock framework. It's used nowhere now. Remove it.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
arch/arm/mach-imx/clk-imx6q.c | 2 --
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/mach-imx6q.c | 1 -
3 files changed, 4 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 7f2c10c..c7e429b 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -56,8 +56,6 @@
static void __iomem *ccm_base;
-void __init imx6q_clock_map_io(void) { }
-
int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode)
{
u32 val = readl_relaxed(ccm_base + CLPCR);
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 7191ab4..7eb3bb2 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -139,7 +139,6 @@ extern void imx_gpc_init(void);
extern void imx_gpc_pre_suspend(void);
extern void imx_gpc_post_resume(void);
extern int imx6q_set_lpm(enum mxc_cpu_pwr_mode mode);
-extern void imx6q_clock_map_io(void);
extern void imx_cpu_die(unsigned int cpu);
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 4eb1b3a..a009df7 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -218,7 +218,6 @@ static void __init imx6q_map_io(void)
{
imx_lluart_map_io();
imx_scu_map_io();
- imx6q_clock_map_io();
}
static const struct of_device_id imx6q_irq_match[] __initconst = {
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ARM: spear3xx: Fix pl080-related build failure
From: Thierry Reding @ 2013-01-17 8:29 UTC (permalink / raw)
To: linux-arm-kernel
Include linux/amba/pl08x.h to pull in the various PL080_* macros.
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
arch/arm/mach-spear3xx/spear3xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-spear3xx/spear3xx.c b/arch/arm/mach-spear3xx/spear3xx.c
index f9d754f..7c218d9 100644
--- a/arch/arm/mach-spear3xx/spear3xx.c
+++ b/arch/arm/mach-spear3xx/spear3xx.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt) "SPEAr3xx: " fmt
#include <linux/amba/pl022.h>
+#include <linux/amba/pl080.h>
#include <linux/amba/pl08x.h>
#include <linux/io.h>
#include <plat/pl080.h>
--
1.8.1.1
^ permalink raw reply related
* [PATCH V3] Add apf51 basic support
From: Shawn Guo @ 2013-01-17 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358183774-4810-1-git-send-email-laurent.cans@gmail.com>
On Mon, Jan 14, 2013 at 06:16:14PM +0100, Laurent Cans wrote:
> Signed-off-by: Laurent Cans <laurent.cans@gmail.com>
> Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@armadeus.com>
> ---
> Differences between v2 and v3
> - remove nand device
> Differences between v1 and v2
> - change board name according project convention
> - remove useless compatible properties
> - add project copyright
> - use device name instead of soc structure for description
> - add an entry for the board on documentation
>
> Documentation/devicetree/bindings/arm/fsl.txt | 4 ++
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/imx51-apf51.dts | 55 +++++++++++++++++++++++++
> arch/arm/boot/dts/imx51.dtsi | 30 ++++++++++++++
> 4 files changed, 91 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/imx51-apf51.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
> index f798187..2549252 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.txt
> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> @@ -13,6 +13,10 @@ i.MX51 Babbage Board
> Required root node properties:
> - compatible = "fsl,imx51-babbage", "fsl,imx51";
>
> +i.MX51 APF51 Board
> +Required root node properties:
> + - compatible = "fsl,imx51-apf51", "fsl,imx51";
> +
fsl.txt is used to documented the boards that are manufactured by
Freescale.
> i.MX53 Automotive Reference Design Board
> Required root node properties:
> - compatible = "fsl,imx53-ard", "fsl,imx53";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e44da40..1acf809 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -79,7 +79,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-370-mirabox.dtb \
> armada-xp-db.dtb \
> armada-xp-openblocks-ax3-4.dtb
> -dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
> +dtb-$(CONFIG_ARCH_MXC) += imx51-apf51.dtb \
> + imx51-babbage.dtb \
> imx53-ard.dtb \
> imx53-evk.dtb \
> imx53-qsb.dtb \
> diff --git a/arch/arm/boot/dts/imx51-apf51.dts b/arch/arm/boot/dts/imx51-apf51.dts
> new file mode 100644
> index 0000000..9239e07
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx51-apf51.dts
> @@ -0,0 +1,55 @@
> +/*
> + * Copyright 2012 Armadeus Systems - <support@armadeus.com>
> + * Copyright 2012 Laurent Cans <laurent.cans@gmail.com>
> + *
> + * Based on mx51-babbage.dts
> + * Copyright 2011 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/dts-v1/;
> +/include/ "imx51.dtsi"
> +
> +/ {
> + model = "Armadeus Systems APF51 module";
> + compatible = "fsl,imx51-apf51", "fsl,imx51";
Replace fsl,imx51-apf51 with something like armadeus,imx51-apf51.
Shawn
> +
> + memory {
> + reg = <0x90000000 0x20000000>;
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
These two lines are not needed, since they are already in imx51.dtsi.
Shawn
> +
> + ckih1 {
> + clock-frequency = <0>;
> + };
> +
> + osc {
> + clock-frequency = <33554432>;
> + };
> + };
> +};
> +
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fec_2>;
> + phy-mode = "mii";
> + phy-reset-gpios = <&gpio3 0 0>;
> + phy-reset-duration = <1>;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart3_2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
> index 1f5d45e..8427279 100644
> --- a/arch/arm/boot/dts/imx51.dtsi
> +++ b/arch/arm/boot/dts/imx51.dtsi
> @@ -273,6 +273,29 @@
> 260 0x80000000 /* MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK */
> >;
> };
> +
> + pinctrl_fec_2: fecgrp-2 {
> + fsl,pins = <
> + 589 0x80000000 /* MX51_PAD_DI_GP3__FEC_TX_ER */
> + 592 0x80000000 /* MX51_PAD_DI2_PIN4__FEC_CRS */
> + 594 0x80000000 /* MX51_PAD_DI2_PIN2__FEC_MDC */
> + 596 0x80000000 /* MX51_PAD_DI2_PIN3__FEC_MDIO */
> + 598 0x80000000 /* MX51_PAD_DI2_DISP_CLK__FEC_RDATA1 */
> + 602 0x80000000 /* MX51_PAD_DI_GP4__FEC_RDATA2 */
> + 604 0x80000000 /* MX51_PAD_DISP2_DAT0__FEC_RDATA3 */
> + 609 0x80000000 /* MX51_PAD_DISP2_DAT1__FEC_RX_ER */
> + 618 0x80000000 /* MX51_PAD_DISP2_DAT6__FEC_TDATA1 */
> + 623 0x80000000 /* MX51_PAD_DISP2_DAT7__FEC_TDATA2 */
> + 628 0x80000000 /* MX51_PAD_DISP2_DAT8__FEC_TDATA3 */
> + 634 0x80000000 /* MX51_PAD_DISP2_DAT9__FEC_TX_EN */
> + 639 0x80000000 /* MX51_PAD_DISP2_DAT10__FEC_COL */
> + 644 0x80000000 /* MX51_PAD_DISP2_DAT11__FEC_RX_CLK */
> + 649 0x80000000 /* MX51_PAD_DISP2_DAT12__FEC_RX_DV */
> + 653 0x80000000 /* MX51_PAD_DISP2_DAT13__FEC_TX_CLK */
> + 657 0x80000000 /* MX51_PAD_DISP2_DAT14__FEC_RDATA0 */
> + 662 0x80000000 /* MX51_PAD_DISP2_DAT15__FEC_TDATA0 */
> + >;
> + };
> };
>
> ecspi1 {
> @@ -409,6 +432,13 @@
> 49 0x1c5 /* MX51_PAD_EIM_D24__UART3_CTS */
> >;
> };
> +
> + pinctrl_uart3_2: uart3grp-2 {
> + fsl,pins = <
> + 434 0x1c5 /* MX51_PAD_UART3_RXD__UART3_RXD */
> + 430 0x1c5 /* MX51_PAD_UART3_TXD__UART3_TXD */
> + >;
> + };
> };
> };
>
> --
> 1.7.10.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] [RFC] ARM: compile fix for DEBUG_LL=y && MMU=n
From: Uwe Kleine-König @ 2013-01-17 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F6FCC0.6040204@gmail.com>
On Wed, Jan 16, 2013 at 01:17:20PM -0600, Rob Herring wrote:
> On 01/16/2013 08:32 AM, Uwe Kleine-K?nig wrote:
> > debug_ll_addr is only used on machines with an MMU so it can be #ifdef'ed
> > out safely. This fixes:
> >
> > arch/arm/kernel/debug.S: Assembler messages:
> > arch/arm/kernel/debug.S:104: Error: too many positional arguments
> >
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: Stephen Warren <swarren@nvidia.com>
> > Cc: Olof Johansson <olof@lixom.net>
> > ---
> > The obvious alternative fix is to make addruart on !MMU take 3
> > arguments, too.
>
> We never envision a need to get the uart address from C code on !MMU?
On MMU addruart takes 3 arguments: physical address output, virtual
address output and a tmp. On !MMU physical == virtual, so only one
register for the address is needed.
(BTW, it was commit 639da5e (ARM: add an extra temp register to the low
level debugging addruart macro) that only changed the MMU variants of
addruart.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v5 4/9] ARM: davinci: da850: added pll0_sysclk1 for DSP usage
From: Sekhar Nori @ 2013-01-17 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357863807-380-5-git-send-email-rtivy@ti.com>
On 1/11/2013 5:53 AM, Robert Tivy wrote:
> Added pll0_sysclk1 to allow clocking control for DSP
>
> Signed-off-by: Robert Tivy <rtivy@ti.com>
Applied patches 3 and 4 as well.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v5 2/9] ARM: davinci: devices-da8xx.c: change pr_warning() to pr_warn()
From: Sekhar Nori @ 2013-01-17 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357863807-380-3-git-send-email-rtivy@ti.com>
On 1/11/2013 5:53 AM, Robert Tivy wrote:
> Changed all pr_warning() calls to pr_warn(), as advised by checkpatch.pl.
>
> Signed-off-by: Robert Tivy <rtivy@ti.com>
> ---
> Clean up files that will be otherwise modified in subsequent patch.
>
> arch/arm/mach-davinci/devices-da8xx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index 2d5502d..fb2f51b 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -751,7 +751,7 @@ void __iomem * __init da8xx_get_mem_ctlr(void)
>
> da8xx_ddr2_ctlr_base = ioremap(DA8XX_DDR2_CTL_BASE, SZ_32K);
> if (!da8xx_ddr2_ctlr_base)
> - pr_warning("%s: Unable to map DDR2 controller", __func__);
> + pr_warn("%s: Unable to map DDR2 controller", __func__);
>
> return da8xx_ddr2_ctlr_base;
> }
> @@ -876,8 +876,8 @@ int __init da8xx_register_spi(int instance, const struct spi_board_info *info,
>
> ret = spi_register_board_info(info, len);
> if (ret)
> - pr_warning("%s: failed to register board info for spi %d :"
> - " %d\n", __func__, instance, ret);
> + pr_warn("%s: failed to register board info for spi %d : %d\n",
> + __func__, instance, ret);
This part is not required anymore since this is already fixed by Vivien
Didelot as part of his SPI fixes. I applied rest of the patch for v3.9.
As with previous patch, I fixed the past tense to present in commit text
while applying.
Thanks,
Sekhar
^ permalink raw reply
* [RFC PATCH 3/4] ARM: bL_entry: Match memory barriers to architectural requirements
From: Santosh Shilimkar @ 2013-01-17 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116150533.GA31318@arm.com>
On Wednesday 16 January 2013 08:35 PM, Catalin Marinas wrote:
> Santosh,
>
> On Wed, Jan 16, 2013 at 06:50:47AM +0000, Santosh Shilimkar wrote:
>> On Tuesday 15 January 2013 10:18 PM, Dave Martin wrote:
>>> For architectural correctness even Strongly-Ordered memory accesses
>>> require barriers in order to guarantee that multiple CPUs have a
>>> coherent view of the ordering of memory accesses.
>>>
>>> Virtually everything done by this early code is done via explicit
>>> memory access only, so DSBs are seldom required. Existing barriers
>>> are demoted to DMB, except where a DSB is needed to synchronise
>>> non-memory signalling (i.e., before a SEV). If a particular
>>> platform performs cache maintenance in its power_up_setup function,
>>> it should force it to complete explicitly including a DSB, instead
>>> of relying on the bL_head framework code to do it.
>>>
>>> Some additional DMBs are added to ensure all the memory ordering
>>> properties required by the race avoidance algorithm. DMBs are also
>>> moved out of loops, and for clarity some are moved so that most
>>> directly follow the memory operation which needs to be
>>> synchronised.
>>>
>>> The setting of a CPU's bL_entry_vectors[] entry is also required to
>>> act as a synchronisation point, so a DMB is added after checking
>>> that entry to ensure that other CPUs do not observe gated
>>> operations leaking across the opening of the gate.
>>>
>>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>>
>> Sorry to pick on this again but I am not able to understand why
>> the strongly ordered access needs barriers. At least from the
>> ARM point of view, a strongly ordered write will be more of blocking
>> write and the further interconnect also is suppose to respect that
>> rule. SO read writes are like adding barrier after every load store
>> so adding explicit barriers doesn't make sense. Is this a side
>> effect of some "write early response" kind of optimizations at
>> interconnect level ?
>
> SO or Device memory accesses are *not* like putting a proper barrier
> between each access, though it may behave in some situations like having
> a barrier. The ARM ARM (A3.8.3, fig 3.5) defines how accesses must
> *arrive* at a peripheral or block of memory depending on the memory type
> and in case of Device or SO we don't need additional barriers because
> such accesses would *arrive* in order (given the minimum 1KB range
> restriction). But it does not say anything about *observability* by a
> different *master*. That's because you can't guarantee that your memory
> accesses go to the same slave port.
>
> For observability by a different master, you need an explicit DMB even
> though the memory type is Device or SO. While it may work fine in most
> cases (especially when the accesses by various masters go to the same
> slave port), you can't be sure what the memory controller or whatever
> interconnect do.
>
I agree that the interconnect behavior and no. of slave port usages
is implementation specific and we can't assume anything here. So
safer side is to have those additional barriers to not hit the corner
cases.
> As Dave said, it's more about what the ARM ARM doesn't say rather than
> what it explicitly states.
>
I understand it better now. Thanks for good discussion.
Regards,
Santosh
^ permalink raw reply
* [PATCH 7/7] ARM i.MX5: Add system reset controller (SRC) to i.MX51 and i.MX53 device tree
From: Shawn Guo @ 2013-01-17 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F72780.8040208@wwwdotorg.org>
On Wed, Jan 16, 2013 at 03:19:44PM -0700, Stephen Warren wrote:
> On 01/16/2013 09:13 AM, Philipp Zabel wrote:
> > Also, link SRC to IPU via phandle.
>
> Aside from the comments I already made, the series,
> Reviewed-by: Stephen Warren <swarren@nvidia.com>
>
> although I'm not 100% sure if the ordering of patches maintains a
> working i.MX build all the time? Does "git bisect" work across the series?
>
> Who would merge these patches?
I would assume IMX --> arm-soc --> mainline?
Philipp, please copy arm-soc folks (Arnd and Olof) on the next post,
so that they can get a chance to review this tiny reset subsystem.
Shawn
^ permalink raw reply
* [PATCH v2 03/10] ARM: dt: tegra30: Add clock information
From: Terje Bergström @ 2013-01-17 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F6E32F.80602@wwwdotorg.org>
On 16.01.2013 19:28, Stephen Warren wrote:
> On 01/16/2013 01:01 AM, Terje Bergstr?m wrote:
>> In Tegra3, 3D has two clocks. I believe you'd need to add <&tegra_car
>> 98> here.
>
> Thanks. I've squashed the following into the patch. Do those clock names
> make sense to you?
>
> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
> index b9709ae..c26d75b 100644
> --- a/arch/arm/boot/dts/tegra30.dtsi
> +++ b/arch/arm/boot/dts/tegra30.dtsi
> @@ -54,7 +54,8 @@
> gr3d {
> compatible = "nvidia,tegra30-gr3d";
> reg = <0x54180000 0x00040000>;
> - clocks = <&tegra_car 24>;
> + clocks = <&tegra_car 24 &tegra_car 98>;
> + clock-names = "3d", "3d2";
> };
>
> dc at 54200000 {
Yep, this looks right.
Terje
^ permalink raw reply
* [PATCH 1/8] SH: intc: Add support OF for INTC
From: Simon Horman @ 2013-01-17 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130110015651.GJ21832@verge.net.au>
On Thu, Jan 10, 2013 at 10:56:51AM +0900, Simon Horman wrote:
> On Wed, Jan 09, 2013 at 07:11:04PM +0000, Arnd Bergmann wrote:
> > On Wednesday 09 January 2013, Mark Rutland wrote:
> > > Hi,
> > >
> > > Thanks for updating the text, this is far easier to read than previously.
> > >
> > > However, I'm still concerned by how complex the binding seems. As I don't have
> > > any familiarity with the device, I don't know whether that's just an artifact
> > > of the hardware or something that can be cleared up.
> > >
> > > I think the approach used by the binding needs some serious review before this
> > > should be merged. It seems far more complex than any existing interrupt
> > > controller binding. Without a dts example for a complete board (complete with
> > > devices wired up to the interrupt controller), it's difficult to judge how this
> > > will work in practice.
> > >
> > > I've added Arnd to Cc in case he has any thoughts on the matter.
> >
> > Sorry for having been absent from this discussion for so long. I didn't
> > realize there were 9 versions of this patch set.
> >
> > I tend to agree with your interpretation above, but I may be missing
> > important facts from the previous review rounds.
> >
> > For all I can tell, the binding is an attempt to describe the
> > entire drivers/sh/intc capabilities, which is probably not the
> > best way to approach things. The sh intc driver is not just an
> > irqchip driver, but rather a framework to describe arbitrary
> > irqchips, which is what makes this so hard.
> >
> > When I first looked at the situation last year, I suggested doing
> > a new irqchip driver with a much simpler binding that can only
> > handle the irq chips from shmobile, rather than the whole thing.
> >
> > I am not sure if the binding in the current form is already the
> > "simplified" version, or if it actually implements all the
> > capabilities of the intc driver.
>
> I think its more on the side of implementing the capabilities of
> the intc driver than being simplified.
>
> Although some effort has gone into this patchset my primary
> aim is to provide something that provides the basis for supporting
> the INTC controller on all existing boards.
>
> I more than open to concrete ideas of how this can be achieved in agreeable way.
>
> > > > + intca: interrupt-controller at 0 {
> > > > + compatible = "renesas,sh_intc";
> > > > + interrupt-controller;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + #interrupt-cells = <1>;
> > > > + ranges;
> > > > +
> > > > + reg = <0xe6940000 0x200>, <0xe6950000 0x200>;
> > > > + group_size = <19>;
> > > > +
> > > > + DIRC: intsrc1 { vector = <0x0560>; };
> > > > + ATAPI: intsrc2 { vector = <0x05E0>; };
> > >
> > > This looks suspiciously like a way of encoding a device's interrupt information
> > > into the interrupt controller's device node. That strikes me as being the wrong
> > > way round.
> >
> > Agreed, it would be simpler to have e.g. #interrupt-cells = <4>, to describe
> > the various offsets when needed (I forgot how many are actually required
> > in practice, rather than being computable from the other numbers), and
> > possibly a global interrupt-map/interrupt-map-mask property pair to map
> > this into a flat number space.
>
> I'm not sure that I see what you are getting at here.
>
> > I need to take some more time to understand the actual requirements again,
> > but IIRC it would be possible to do something much simpler than the
> > proposed binding.
Ping
^ permalink raw reply
* [PATCH] ARM: mm: Fix missing XN flag for for MT_MEMORY_SO
From: Santosh Shilimkar @ 2013-01-17 6:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116231631.GW23505@n2100.arm.linux.org.uk>
On Thursday 17 January 2013 04:46 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 16, 2013 at 08:19:22PM +0530, Santosh Shilimkar wrote:
>> Commit 8fb54284ba6a {ARM: mm: Add strongly ordered descriptor support}
>> added XN flag at section level but missed it at PTE level.
>>
>> Fix it by adding the L_PTE_XN to MT_MEMORY_SO PET descriptor.
>>
>> Cc: Russell King <linux@arm.linux.org.uk>
>>
>> Reported-by: Richard Woodruff <r-woodruff2@ti.com>
>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> ---
>
> Hmm, yes. => patch system please.
>
7629/1 in patch system.
Regards,
Santosh
^ permalink raw reply
* [PATCH 6/7] ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53
From: Shawn Guo @ 2013-01-17 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358352787-15441-7-git-send-email-p.zabel@pengutronix.de>
On Wed, Jan 16, 2013 at 05:13:06PM +0100, Philipp Zabel wrote:
> The SRC in i.MX51 and i.MX53 is similar to the one in i.MX6q minus
> the IPU2 reset line and multi core CPU reset/enable bits.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> arch/arm/mach-imx/Kconfig | 1 +
> arch/arm/mach-imx/common.h | 3 ++-
> arch/arm/mach-imx/mach-imx6q.c | 2 +-
> arch/arm/mach-imx/mm-imx5.c | 2 ++
> arch/arm/mach-imx/src.c | 14 +++++++++++++-
> 5 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 3e628fd..d7924e5 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -829,6 +829,7 @@ config SOC_IMX53
> select ARCH_MX53
> select HAVE_CAN_FLEXCAN if CAN
> select IMX_HAVE_PLATFORM_IMX2_WDT
> + select HAVE_IMX_SRC
Please sort it in name. Should we manage to have it selected for imx51
too, since you have code added for imx51 below?
> select PINCTRL
> select PINCTRL_IMX53
> select SOC_IMX5
> diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
> index 7191ab4..f36be3c 100644
> --- a/arch/arm/mach-imx/common.h
> +++ b/arch/arm/mach-imx/common.h
> @@ -133,7 +133,8 @@ static inline void imx_smp_prepare(void) {}
> #endif
> extern void imx_enable_cpu(int cpu, bool enable);
> extern void imx_set_cpu_jump(int cpu, void *jump_addr);
> -extern void imx_src_init(void);
> +extern void imx5_src_init(void);
> +extern void imx6q_src_init(void);
> extern void imx_src_prepare_restart(void);
> extern void imx_gpc_init(void);
> extern void imx_gpc_pre_suspend(void);
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index cd277a0..b1e076c 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -229,7 +229,7 @@ static const struct of_device_id imx6q_irq_match[] __initconst = {
> static void __init imx6q_init_irq(void)
> {
> l2x0_of_init(0, ~0UL);
> - imx_src_init();
> + imx6q_src_init();
I'm not sure this is necessary. See below ...
> imx_gpc_init();
> of_irq_init(imx6q_irq_match);
> }
> diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
> index 79d71cf..53f87be 100644
> --- a/arch/arm/mach-imx/mm-imx5.c
> +++ b/arch/arm/mach-imx/mm-imx5.c
> @@ -106,6 +106,7 @@ void __init imx51_init_early(void)
> mxc_set_cpu_type(MXC_CPU_MX51);
> mxc_iomux_v3_init(MX51_IO_ADDRESS(MX51_IOMUXC_BASE_ADDR));
> mxc_arch_reset_init(MX51_IO_ADDRESS(MX51_WDOG1_BASE_ADDR));
> + imx5_src_init();
> }
>
> void __init imx53_init_early(void)
> @@ -113,6 +114,7 @@ void __init imx53_init_early(void)
> mxc_set_cpu_type(MXC_CPU_MX53);
> mxc_iomux_v3_init(MX53_IO_ADDRESS(MX53_IOMUXC_BASE_ADDR));
> mxc_arch_reset_init(MX53_IO_ADDRESS(MX53_WDOG1_BASE_ADDR));
> + imx5_src_init();
> }
>
> void __init mx50_init_irq(void)
> diff --git a/arch/arm/mach-imx/src.c b/arch/arm/mach-imx/src.c
> index 41687c6..e350250 100644
> --- a/arch/arm/mach-imx/src.c
> +++ b/arch/arm/mach-imx/src.c
> @@ -125,7 +125,19 @@ void imx_src_prepare_restart(void)
> writel_relaxed(0, src_base + SRC_GPR1);
> }
>
> -void __init imx_src_init(void)
> +void __init imx5_src_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,imx5-src");
In fsl,imx-src.txt, we have
compatible: Should be "fsl,<chip>-src"
But imx5 is not a chip name. I would suggest we have the imx-src driver
only look for compatible "fsl,imx51-src", and for dts
imx51: compatible = "fsl,imx51-src";
imx53: compatible = "fsl,imx53-src", "fsl,imx51-src";
imx6q: compatible = "fsl,imx6q-src", "fsl,imx51-src";
so that we do not need imx5_src_init and imx6q_src_init which are
basically doing the same thing.
> + src_base = of_iomap(np, 0);
> + WARN_ON(!src_base);
As imx51 still supports non-DT boot, we should have a check on np.
If np is NULL, mostly likely it's a non-DT boot on imx51, and we
should bail out instead of giving a fat warning.
Shawn
> +
> + imx_reset_controller.of_node = np;
> + reset_controller_register(&imx_reset_controller);
> +}
> +
> +void __init imx6q_src_init(void)
> {
> struct device_node *np;
> u32 val;
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 0/8] ARM: shmobile: pinctrl and DT extensions
From: Simon Horman @ 2013-01-17 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
On Wed, Jan 16, 2013 at 06:08:09PM +0100, Guennadi Liakhovetski wrote:
> These patches extend sh7372 and r8a7740 pinctrl support and use it to add
> SDHI and MMCIF to armadillo800eva and mackerel reference DT
> implementations. GPIO-based pin configuration is removed from board files.
> Additionally, MMC interfaces on armadillo800eva support run-time
> power-switching, which is also supported in DT with these patches.
>
> This series is based on recent work by Laurent and Simon. sh7372 and
> r8a7740 pinctrl support seems to be stable and, probably, won't change,
> so, also the base for these patches seems solid. Since the current pinctrl
> implementation for sh73a0 is likely to change, support for kzm9g isn't
> included in this series.
Thanks.
As these depend on at least one outstanding series from Laurent,
I'm going to wait for some fresh patches from him before applying this.
^ permalink raw reply
* [PATCH v2] drivers/pinctrl: grab default handles from device core
From: Simon Horman @ 2013-01-17 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F6E811.2040606@wwwdotorg.org>
On Wed, Jan 16, 2013 at 10:49:05AM -0700, Stephen Warren wrote:
> On 01/11/2013 01:45 PM, Linus Walleij wrote:
> > On Fri, Jan 11, 2013 at 9:36 PM, Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> >
> >> I've sent several patch series for the SH PFC (Pin Function Controller) to the
> >> linux-sh mailing list. One of the series included pinctrl core patches for
> >> easier testing, but I made it clear that they should *not* be pushed to
> >> mainline through the SH tree.
> >
> > No big deal, what fun is linux-next if we don't break it ;-)
>
> Hmm. It's causing a lot of engineers here a lot of trouble, since they
> all see linux-next won't boot, and haven't been paying enough attention
> to know which commit to revert:-(. Lots of lost productivity:-(
>
> Simon, the offending commit:
>
> 6d3ef6b drivers/pinctrl: grab default handles from device core
>
> is still in next-20130116. Can you please remove it?
I removed the commit yesterday.
Please let me know if it seems to be lingering.
^ permalink raw reply
* linux-next: manual merge of the samsung tree with the arm-soc tree
From: Stephen Rothwell @ 2013-01-17 5:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0c9401cdf471$53f7c140$fbe743c0$@samsung.com>
Hi Kukjin,
On Wed, 16 Jan 2013 21:13:00 -0800 Kukjin Kim <kgene.kim@samsung.com> wrote:
>
> One more, following is my preferred resolution when merge conflict happens
> between Samsung tree and arm-soc tree:
Thanks, I will use this resolution tomorrow. You will still get
notification emails just to double check.
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/0cbcdf59/attachment.sig>
^ permalink raw reply
* [PATCH 4/7] ARM i.MX6q: Link system reset controller (SRC) to IPU in DT
From: Shawn Guo @ 2013-01-17 5:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358352787-15441-5-git-send-email-p.zabel@pengutronix.de>
On Wed, Jan 16, 2013 at 05:13:04PM +0100, Philipp Zabel wrote:
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> arch/arm/boot/dts/imx6q.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index d6265ca..c445959 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -555,6 +555,7 @@
> compatible = "fsl,imx6q-src";
> reg = <0x020d8000 0x4000>;
> interrupts = <0 91 0x04 0 96 0x04>;
> + #reset-cells = <1>;
> };
>
> gpc: gpc at 020dc000 {
> @@ -1046,6 +1047,7 @@
> interrupts = <0 6 0x4 0 5 0x4>;
> clocks = <&clks 130>, <&clks 131>, <&clks 132>;
> clock-names = "bus", "di0", "di1";
> + resets = <&src 2>;
> };
>
> ipu2: ipu at 02800000 {
> @@ -1055,6 +1057,7 @@
> interrupts = <0 8 0x4 0 7 0x4>;
> clocks = <&clks 133>, <&clks 134>, <&clks 137>;
> clock-names = "bus", "di0", "di1";
> + reset = <&src 4>;
s/reset/resets
Shawn
> };
> };
> };
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH 3/7] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC)
From: Shawn Guo @ 2013-01-17 5:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358352787-15441-4-git-send-email-p.zabel@pengutronix.de>
On Wed, Jan 16, 2013 at 05:13:03PM +0100, Philipp Zabel wrote:
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/smp.h>
> +#include <linux/reset-controller.h>
Move it one line above to have it sorted.
> #include <asm/smp_plat.h>
...
> --- /dev/null
> +++ b/include/linux/imx-src.h
> @@ -0,0 +1,6 @@
> +#ifndef __IMX_SRC_H__
> +#define __IMX_SRC_H__
> +
> +extern int imx_src_reset(int sw_reset_idx);
> +
> +#endif /* __IMX_SRC_H__ */
This is header is not needed any more.
Shawn
^ permalink raw reply
* [PATCH 2/7] reset: Add reset controller API
From: Shawn Guo @ 2013-01-17 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358352787-15441-3-git-send-email-p.zabel@pengutronix.de>
On Wed, Jan 16, 2013 at 05:13:02PM +0100, Philipp Zabel wrote:
> +#include <linux/reset.h>
> +#include <linux/reset-controller.h>
I failed to find these two headers in the series.
Shawn
^ permalink raw reply
* linux-next: manual merge of the samsung tree with the arm-soc tree
From: Kukjin Kim @ 2013-01-17 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117145324.3f1f27fb5902b5a03135bf06@canb.auug.org.au>
Kukjin Kim wrote:
[...]
> Hmm, updating timer patches in Samsung tree cause the merge conflicts with
> arm-soc, so for now I dropped them in my tree just now.
> And note that regarding topic branch which are including it will be
re-worked
> soon :-)
>
> Now to merge Samsung tree for linux-next should be fine.
>
> Thanks again.
>
One more, following is my preferred resolution when merge conflict happens
between Samsung tree and arm-soc tree:
8<---------------------------------------------------
diff --cc arch/arm/common/Makefile
index 55d4182,dc8dd0d..7a5df8b
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@@ -2,10 -2,6 +2,8 @@@
# Makefile for the linux kernel.
#
+obj-y += firmware.o
+
- obj-$(CONFIG_ARM_GIC) += gic.o
- obj-$(CONFIG_ARM_VIC) += vic.o
obj-$(CONFIG_ICST) += icst.o
obj-$(CONFIG_SA1111) += sa1111.o
obj-$(CONFIG_PCI_HOST_VIA82C505) += via82c505.o
diff --cc arch/arm/mach-exynos/mach-exynos4-dt.c
index ab1dacc,112d10e..3ac73ed
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@@ -107,11 -106,9 +106,10 @@@ DT_MACHINE_START(EXYNOS4210_DT, "Samsun
.smp = smp_ops(exynos_smp_ops),
.init_irq = exynos4_init_irq,
.map_io = exynos4_dt_map_io,
- .handle_irq = gic_handle_irq,
+ .init_early = exynos_firmware_init,
.init_machine = exynos4_dt_machine_init,
.init_late = exynos_init_late,
- .timer = &exynos4_timer,
+ .init_time = exynos4_timer_init,
.dt_compat = exynos4_dt_compat,
.restart = exynos4_restart,
MACHINE_END
diff --cc arch/arm/mach-exynos/platsmp.c
index 3226893,60f7c5b..a083e05
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@@ -20,12 -20,11 +20,12 @@@
#include <linux/jiffies.h>
#include <linux/smp.h>
#include <linux/io.h>
+ #include <linux/irqchip/arm-gic.h>
#include <asm/cacheflush.h>
- #include <asm/hardware/gic.h>
#include <asm/smp_plat.h>
#include <asm/smp_scu.h>
+#include <asm/firmware.h>
#include <mach/hardware.h>
#include <mach/regs-clock.h>
@@@ -146,22 -145,11 +146,22 @@@ static int __cpuinit exynos_boot_second
timeout = jiffies + (1 * HZ);
while (time_before(jiffies, timeout)) {
+ unsigned long boot_addr;
+
smp_rmb();
- __raw_writel(virt_to_phys(exynos4_secondary_startup),
-
cpu_boot_reg(phys_cpu));
+ boot_addr = virt_to_phys(exynos4_secondary_startup);
+
+ /*
+ * Try to set boot address using firmware first
+ * and fall back to boot register if it fails.
+ */
+ if (call_firmware_op(set_cpu_boot_addr, phys_cpu,
boot_addr))
+ __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
+
+ call_firmware_op(cpu_boot, phys_cpu);
+
- gic_raise_softirq(cpumask_of(cpu), 0);
+ arch_send_wakeup_ipi_mask(cpumask_of(cpu));
if (pen_release == -1)
break;
^ permalink raw reply
* [PATCH v4 2/9] clk: tegra: Add tegra specific clocks
From: Hiroshi Doyu @ 2013-01-17 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7096C.7020803@wwwdotorg.org>
Stephen Warren <swarren@wwwdotorg.org> wrote @ Wed, 16 Jan 2013 21:11:24 +0100:
> >> +static int clk_frac_div_set_rate(struct clk_hw *hw, unsigned long rate,
> >> + unsigned long parent_rate)
> >> +{
> >> + struct tegra_clk_frac_div *divider = to_clk_frac_div(hw);
> >> + int div;
> >> + unsigned long flags = 0;
> >
> > nit, is "flags" not needed to initialize here?
>
> It avoids a compiler warning; the compiler doesn't that the if condition
> that guards the path that uses flags is the same condition as the path
> that initializes it. Or, it may be related to the fact that
> spin_lock_irqsave() writes to the value through a pointer parameter, and
> the compiler doesn't know it's an out-only parameter.
It might be better to append the special comment /* GCC */[1] on that line.
[1] https://lwn.net/Articles/529954/
^ permalink raw reply
* linux-next: manual merge of the samsung tree with the arm-soc tree
From: Kukjin Kim @ 2013-01-17 5:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117145324.3f1f27fb5902b5a03135bf06@canb.auug.org.au>
Kukjin Kim wrote:
>
> Stephen Rothwell wrote:
> >
> > Hi Kukjin,
> >
> Hi,
>
> > On Fri, 11 Jan 2013 15:32:06 +1100 Stephen Rothwell
> <sfr@canb.auug.org.au>
> > wrote:
> > >
> > > Today's linux-next merge of the samsung tree got conflicts in
> > > many files with the arm-soc tree.
> > >
> > > I just dropped the samsung tree for today. Please have a look and try
to
> > > fix this mess up, thanks.
> >
> > Ping?
>
> Oops, I missed above e-mail. Anyway, really?
>
> Let me look at it soon and I will fix.
>
> Thanks for your information.
>
Hmm, updating timer patches in Samsung tree cause the merge conflicts with
arm-soc, so for now I dropped them in my tree just now.
And note that regarding topic branch which are including it will be
re-worked soon :-)
Now to merge Samsung tree for linux-next should be fine.
Thanks again.
- Kukjin
^ 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