* [RFC PATCH 2/2] ARM: OMAP4: clock: use omap4_clks_register API
From: Mike Turquette @ 2012-10-22 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <902E09E6452B0E43903E4F2D568737AB2CA620@DNCE04.ent.ti.com>
Quoting Strashko, Grygorii (2012-10-19 03:34:19)
> Hi Mike,
>
> > In addition to removing CK_443X/CK_446X you could also get rid of struct
> > omap_clk completely (arch/arm/plat-omap/include/plat/clkdev_omap.h) and
> > the CLK macro by changing the clk array to be of type struct clk_lookup
> > and using the CLKDEV_INIT macro.
> Yes. It may be done. As I understand, this approach is applicable for you, if so i can continue working on it. right?
>
> > I wonder if splitting the tables would make initdata any easier. It
> OMAP5,4,2 - there are no so much differences between SOcs, so it looks good and simple.
> OMAP3 - it is a little bit more complex.
> > would be nice to get more functional changes out of this series
> > alongside the data reorganization.
> Could you provide more details, pls?
>
What I mean to say is that this patch doesn't change any functionality.
It just reorganizes data to make things prettier. In order to justify
getting this change upstream (and to combat accusations of "needless
churn") it would be good if this series did more than just shuffle the
data around. Two examples I have already mentioned are getting rid of
the macros in ckdev_omap.h (and maybe getting rid of that entire file)
and also marking data as initdata. Both are functional changes that
make the world a better place.
Regards,
Mike
> > Also have you looked at splitting the tables for OMAP2/3?
> Yes. I think, it can be done.
>
> Best regards,
> Grygorii Strashko | GlobalLogic
>
> ________________________________________
> From: Mike Turquette [mturquette at linaro.org]
> Sent: Thursday, October 18, 2012 8:53 PM
> To: Strashko, Grygorii; Paul Walmsley
> Cc: Hilman, Kevin; Tony Lindgren; linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Strashko, Grygorii
> Subject: Re: [RFC PATCH 2/2] ARM: OMAP4: clock: use omap4_clks_register API
>
> Quoting Grygorii Strashko (2012-10-18 09:38:17)
> > Remove OMAP443x and OMAP446x specific clocks from omap44xx_clks
> > array and add corresponding set of clocks per each SoC:
> > - struct omap_clk omap44xx_clks[]; - common clocks set for all OMAP4
> > - struct omap_clk omap443x_clks[]; - specific clocks set for OMAP443x
> > - struct omap_clk omap446x_clks[]; - specific clocks set for OMAP446x
> > and don't rely on platform specific flags any more.
> >
> > Use omap4_clks_register() API to register and init OMAP4 set of
> > clocks.
> >
> > With this change, we can now safely remove CK_443X/CK_446X etc macro
> > usage. It has not been done in this patch, but if the approach is OK,
> > then, it is possible to do the same.
> >
>
> In addition to removing CK_443X/CK_446X you could also get rid of struct
> omap_clk completely (arch/arm/plat-omap/include/plat/clkdev_omap.h) and
> the CLK macro by changing the clk array to be of type struct clk_lookup
> and using the CLKDEV_INIT macro.
>
> > One additional benefit seen is that the match logic can entirely be
> > skipped.
> >
>
> I wonder if splitting the tables would make initdata any easier. It
> would be nice to get more functional changes out of this series
> alongside the data reorganization.
>
> Also have you looked at splitting the tables for OMAP2/3?
>
> Regards,
> Mike
>
> > Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> > ---
> > arch/arm/mach-omap2/clock44xx_data.c | 40 ++++++++++++++++++----------------
> > 1 file changed, 21 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
> > index 6efc30c..4060c9c 100644
> > --- a/arch/arm/mach-omap2/clock44xx_data.c
> > +++ b/arch/arm/mach-omap2/clock44xx_data.c
> > @@ -3145,10 +3145,7 @@ static struct omap_clk omap44xx_clks[] = {
> > CLK(NULL, "aes1_fck", &aes1_fck, CK_443X),
> > CLK(NULL, "aes2_fck", &aes2_fck, CK_443X),
> > CLK(NULL, "aess_fck", &aess_fck, CK_443X),
> > - CLK(NULL, "bandgap_fclk", &bandgap_fclk, CK_443X),
> > - CLK(NULL, "bandgap_ts_fclk", &bandgap_ts_fclk, CK_446X),
> > CLK(NULL, "des3des_fck", &des3des_fck, CK_443X),
> > - CLK(NULL, "div_ts_ck", &div_ts_ck, CK_446X),
> > CLK(NULL, "dmic_sync_mux_ck", &dmic_sync_mux_ck, CK_443X),
> > CLK(NULL, "dmic_fck", &dmic_fck, CK_443X),
> > CLK(NULL, "dsp_fck", &dsp_fck, CK_443X),
> > @@ -3346,19 +3343,27 @@ static struct omap_clk omap44xx_clks[] = {
> > CLK("4903c000.timer", "timer_sys_ck", &syc_clk_div_ck, CK_443X),
> > CLK("4903e000.timer", "timer_sys_ck", &syc_clk_div_ck, CK_443X),
> > CLK(NULL, "cpufreq_ck", &dpll_mpu_ck, CK_443X),
> > + CLK(NULL, NULL, NULL, CK_443X),
> > +};
> > +
> > +static struct omap_clk omap443x_clks[] = {
> > + CLK(NULL, "bandgap_fclk", &bandgap_fclk, CK_443X),
> > + CLK(NULL, NULL, NULL, CK_443X),
> > +};
> > +
> > +
> > +static struct omap_clk omap446x_clks[] = {
> > + CLK(NULL, "div_ts_ck", &div_ts_ck, CK_446X),
> > + CLK(NULL, "bandgap_ts_fclk", &bandgap_ts_fclk, CK_446X),
> > + CLK(NULL, NULL, NULL, CK_446X),
> > };
> >
> > int __init omap4xxx_clk_init(void)
> > {
> > - struct omap_clk *c;
> > - u32 cpu_clkflg;
> > -
> > if (cpu_is_omap443x()) {
> > cpu_mask = RATE_IN_4430;
> > - cpu_clkflg = CK_443X;
> > } else if (cpu_is_omap446x() || cpu_is_omap447x()) {
> > cpu_mask = RATE_IN_4460 | RATE_IN_4430;
> > - cpu_clkflg = CK_446X | CK_443X;
> >
> > if (cpu_is_omap447x())
> > pr_warn("WARNING: OMAP4470 clock data incomplete!\n");
> > @@ -3375,17 +3380,14 @@ int __init omap4xxx_clk_init(void)
> > * omap2_clk_disable_clkdm_control();
> > */
> >
> > - for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
> > - c++)
> > - clk_preinit(c->lk.clk);
> > -
> > - for (c = omap44xx_clks; c < omap44xx_clks + ARRAY_SIZE(omap44xx_clks);
> > - c++)
> > - if (c->cpu & cpu_clkflg) {
> > - clkdev_add(&c->lk);
> > - clk_register(c->lk.clk);
> > - omap2_init_clk_clkdm(c->lk.clk);
> > - }
> > + omap2_clks_register(omap44xx_clks);
> > +
> > + if (cpu_is_omap443x())
> > + omap2_clks_register(omap443x_clks);
> > + else if (cpu_is_omap446x() || cpu_is_omap447x())
> > + omap2_clks_register(omap446x_clks);
> > + else
> > + return 0;
> >
> > /* Disable autoidle on all clocks; let the PM code enable it later */
> > omap_clk_disable_autoidle_all();
> > --
> > 1.7.9.5
^ permalink raw reply
* [PATCH v2 4/4] zynq: remove use of CLKDEV_LOOKUP
From: Josh Cartwright @ 2012-10-22 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022211040.GA31538@beefymiracle.amer.corp.natinst.com>
The Zynq support in mainline does not (yet) make use of any of the
generic clk or clk lookup functionality. Remove what is upstream for
now, until the out-of-tree implementation is in suitable form for
merging.
An important side effect of this patch is that it allows the building of
a Zynq kernel without running into unresolved symbol problems:
drivers/built-in.o: In function `amba_get_enable_pclk':
clkdev.c:(.text+0x444): undefined reference to `clk_enable'
drivers/built-in.o: In function `amba_remove':
clkdev.c:(.text+0x488): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_probe':
clkdev.c:(.text+0x540): undefined reference to `clk_disable'
drivers/built-in.o: In function `amba_device_add':
clkdev.c:(.text+0x77c): undefined reference to `clk_disable'
drivers/built-in.o: In function `enable_clock':
clkdev.c:(.text+0x29738): undefined reference to `clk_enable'
drivers/built-in.o: In function `disable_clock':
clkdev.c:(.text+0x29778): undefined reference to `clk_disable'
drivers/built-in.o: In function `__pm_clk_remove':
clkdev.c:(.text+0x297f8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_suspend':
clkdev.c:(.text+0x29bc8): undefined reference to `clk_disable'
drivers/built-in.o: In function `pm_clk_resume':
clkdev.c:(.text+0x29c28): undefined reference to `clk_enable'
make[2]: *** [vmlinux] Error 1
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
arch/arm/Kconfig | 1 -
arch/arm/mach-zynq/common.c | 1 -
arch/arm/mach-zynq/include/mach/clkdev.h | 32 --------------------------------
3 files changed, 34 deletions(-)
delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cce4f8d..de70d99 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -946,7 +946,6 @@ config ARCH_ZYNQ
bool "Xilinx Zynq ARM Cortex A9 Platform"
select ARM_AMBA
select ARM_GIC
- select CLKDEV_LOOKUP
select CPU_V7
select GENERIC_CLOCKEVENTS
select ICST
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index e4e422b..e10268c 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -31,7 +31,6 @@
#include <asm/hardware/cache-l2x0.h>
#include <mach/zynq_soc.h>
-#include <mach/clkdev.h>
#include "common.h"
static struct of_device_id zynq_of_bus_ids[] __initdata = {
diff --git a/arch/arm/mach-zynq/include/mach/clkdev.h b/arch/arm/mach-zynq/include/mach/clkdev.h
deleted file mode 100644
index c6e73d8..0000000
--- a/arch/arm/mach-zynq/include/mach/clkdev.h
+++ /dev/null
@@ -1,32 +0,0 @@
-/*
- * arch/arm/mach-zynq/include/mach/clkdev.h
- *
- * Copyright (C) 2011 Xilinx, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#ifndef __MACH_CLKDEV_H__
-#define __MACH_CLKDEV_H__
-
-#include <plat/clock.h>
-
-struct clk {
- unsigned long rate;
- const struct clk_ops *ops;
- const struct icst_params *params;
- void __iomem *vcoreg;
-};
-
-#define __clk_get(clk) ({ 1; })
-#define __clk_put(clk) do { } while (0)
-
-#endif
--
1.8.0
^ permalink raw reply related
* [PATCH v2 3/4] zynq: use GIC device tree bindings
From: Josh Cartwright @ 2012-10-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022211040.GA31538@beefymiracle.amer.corp.natinst.com>
The Zynq uses the cortex-a9-gic. This eliminates the need to hardcode
register addresses.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
arch/arm/boot/dts/zynq-ep107.dts | 8 +++++---
arch/arm/mach-zynq/common.c | 7 ++++++-
arch/arm/mach-zynq/include/mach/zynq_soc.h | 2 --
3 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-ep107.dts b/arch/arm/boot/dts/zynq-ep107.dts
index 37ca192..7bfff4a 100644
--- a/arch/arm/boot/dts/zynq-ep107.dts
+++ b/arch/arm/boot/dts/zynq-ep107.dts
@@ -36,10 +36,12 @@
ranges;
intc: interrupt-controller at f8f01000 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <1>;
interrupt-controller;
- compatible = "arm,gic";
- reg = <0xF8F01000 0x1000>;
- #interrupt-cells = <2>;
+ reg = <0xF8F01000 0x1000>,
+ <0xF8F00100 0x100>;
};
uart0: uart at e0000000 {
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index b33f12f..e4e422b 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -55,12 +55,17 @@ static void __init xilinx_init_machine(void)
of_platform_bus_probe(NULL, zynq_of_bus_ids, NULL);
}
+static struct of_device_id irq_match[] __initdata = {
+ { .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
+ { }
+};
+
/**
* xilinx_irq_init() - Interrupt controller initialization for the GIC.
*/
static void __init xilinx_irq_init(void)
{
- gic_init(0, 29, SCU_GIC_DIST_BASE, SCU_GIC_CPU_BASE);
+ of_irq_init(irq_match);
}
/* The minimum devices needed to be mapped before the VM system is up and
diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h b/arch/arm/mach-zynq/include/mach/zynq_soc.h
index ae3b236..9156914 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -42,8 +42,6 @@
#define TTC0_BASE IOMEM(TTC0_VIRT)
#define SCU_PERIPH_BASE IOMEM(SCU_PERIPH_VIRT)
-#define SCU_GIC_CPU_BASE (SCU_PERIPH_BASE + 0x100)
-#define SCU_GIC_DIST_BASE (SCU_PERIPH_BASE + 0x1000)
#define PL310_L2CC_BASE IOMEM(PL310_L2CC_VIRT)
#define LL_UART_PADDR UART0_PHYS
--
1.8.0
^ permalink raw reply related
* [PATCH v2 2/4] zynq: move static peripheral mappings
From: Josh Cartwright @ 2012-10-22 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022211040.GA31538@beefymiracle.amer.corp.natinst.com>
Shifting them up into the vmalloc region prevents the following warning,
when booting a zynq qemu target with more than 512mb of RAM:
BUG: mapping for 0xe0000000 at 0xe0000000 out of vmalloc space
In addition, it allows for reuse of these mappings when the proper
drivers issue requests via ioremap().
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
arch/arm/mach-zynq/common.c | 8 +++----
arch/arm/mach-zynq/include/mach/zynq_soc.h | 38 +++++++++++++++++-------------
2 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index ab5cfdd..b33f12f 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -71,17 +71,17 @@ static struct map_desc io_desc[] __initdata = {
{
.virtual = TTC0_VIRT,
.pfn = __phys_to_pfn(TTC0_PHYS),
- .length = SZ_4K,
+ .length = TTC0_SIZE,
.type = MT_DEVICE,
}, {
.virtual = SCU_PERIPH_VIRT,
.pfn = __phys_to_pfn(SCU_PERIPH_PHYS),
- .length = SZ_8K,
+ .length = SCU_PERIPH_SIZE,
.type = MT_DEVICE,
}, {
.virtual = PL310_L2CC_VIRT,
.pfn = __phys_to_pfn(PL310_L2CC_PHYS),
- .length = SZ_4K,
+ .length = PL310_L2CC_SIZE,
.type = MT_DEVICE,
},
@@ -89,7 +89,7 @@ static struct map_desc io_desc[] __initdata = {
{
.virtual = UART0_VIRT,
.pfn = __phys_to_pfn(UART0_PHYS),
- .length = SZ_4K,
+ .length = UART0_SIZE,
.type = MT_DEVICE,
},
#endif
diff --git a/arch/arm/mach-zynq/include/mach/zynq_soc.h b/arch/arm/mach-zynq/include/mach/zynq_soc.h
index d0d3f8f..ae3b236 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -15,33 +15,37 @@
#ifndef __MACH_XILINX_SOC_H__
#define __MACH_XILINX_SOC_H__
+#include <asm/pgtable.h>
+
#define PERIPHERAL_CLOCK_RATE 2500000
-/* For now, all mappings are flat (physical = virtual)
+/* Static peripheral mappings are mapped at the top of the
+ * vmalloc region
*/
-#define UART0_PHYS 0xE0000000
-#define UART0_VIRT UART0_PHYS
+#define UART0_PHYS 0xE0000000
+#define UART0_SIZE SZ_4K
+#define UART0_VIRT (VMALLOC_END - UART0_SIZE)
-#define TTC0_PHYS 0xF8001000
-#define TTC0_VIRT TTC0_PHYS
+#define TTC0_PHYS 0xF8001000
+#define TTC0_SIZE SZ_4K
+#define TTC0_VIRT (UART0_VIRT - TTC0_SIZE)
-#define PL310_L2CC_PHYS 0xF8F02000
-#define PL310_L2CC_VIRT PL310_L2CC_PHYS
+#define PL310_L2CC_PHYS 0xF8F02000
+#define PL310_L2CC_SIZE SZ_4K
+#define PL310_L2CC_VIRT (TTC0_VIRT - PL310_L2CC_SIZE)
-#define SCU_PERIPH_PHYS 0xF8F00000
-#define SCU_PERIPH_VIRT SCU_PERIPH_PHYS
+#define SCU_PERIPH_PHYS 0xF8F00000
+#define SCU_PERIPH_SIZE SZ_8K
+#define SCU_PERIPH_VIRT (PL310_L2CC_VIRT - SCU_PERIPH_SIZE)
/* The following are intended for the devices that are mapped early */
-#define TTC0_BASE IOMEM(TTC0_VIRT)
-#define SCU_PERIPH_BASE IOMEM(SCU_PERIPH_VIRT)
-#define SCU_GIC_CPU_BASE (SCU_PERIPH_BASE + 0x100)
-#define SCU_GIC_DIST_BASE (SCU_PERIPH_BASE + 0x1000)
-#define PL310_L2CC_BASE IOMEM(PL310_L2CC_VIRT)
+#define TTC0_BASE IOMEM(TTC0_VIRT)
+#define SCU_PERIPH_BASE IOMEM(SCU_PERIPH_VIRT)
+#define SCU_GIC_CPU_BASE (SCU_PERIPH_BASE + 0x100)
+#define SCU_GIC_DIST_BASE (SCU_PERIPH_BASE + 0x1000)
+#define PL310_L2CC_BASE IOMEM(PL310_L2CC_VIRT)
-/*
- * Mandatory for CONFIG_LL_DEBUG, UART is mapped virtual = physical
- */
#define LL_UART_PADDR UART0_PHYS
#define LL_UART_VADDR UART0_VIRT
--
1.8.0
^ permalink raw reply related
* [PATCH v2 1/4] ARM: annotate VMALLOC_END definition with _AC
From: Josh Cartwright @ 2012-10-22 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022211040.GA31538@beefymiracle.amer.corp.natinst.com>
This makes the definition of VMALLOC_END suitable for use within
assembly code. This is necessary to allow the use of VMALLOC_END in
defining where the early uart is mapped for use with DEBUG_LL.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
---
arch/arm/include/asm/pgtable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 08c1231..72904a2 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -40,7 +40,7 @@
*/
#define VMALLOC_OFFSET (8*1024*1024)
#define VMALLOC_START (((unsigned long)high_memory + VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1))
-#define VMALLOC_END 0xff000000UL
+#define VMALLOC_END _AC(0xff000000,UL)
#define LIBRARY_TEXT_START 0x0c000000
--
1.8.0
^ permalink raw reply related
* [PATCH 3/5] arm: mvebu: Added IPI support via doorbells
From: Gregory CLEMENT @ 2012-10-22 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022200708.GO21046@lunn.ch>
On 10/22/2012 10:07 PM, Andrew Lunn wrote:
> On Mon, Oct 22, 2012 at 09:07:34PM +0200, Gregory CLEMENT wrote:
>> On 10/22/2012 07:30 PM, Andrew Lunn wrote:
>>> On Mon, Oct 22, 2012 at 07:02:45PM +0200, Gregory CLEMENT wrote:
>>>> From: Yehuda Yitschak <yehuday@marvell.com>
>>>>
>>>> Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
>>>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>>> ---
>>>> arch/arm/boot/dts/armada-xp.dtsi | 2 +-
>>>> arch/arm/mach-mvebu/armada-370-xp.h | 10 ++++
>>>> arch/arm/mach-mvebu/irq-armada-370-xp.c | 92 +++++++++++++++++++++++++++++--
>>>> 3 files changed, 97 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
>>>> index f521ed8..531619f 100644
>>>> --- a/arch/arm/boot/dts/armada-xp.dtsi
>>>> +++ b/arch/arm/boot/dts/armada-xp.dtsi
>>>> @@ -24,7 +24,7 @@
>>>>
>>>> mpic: interrupt-controller at d0020000 {
>>>> reg = <0xd0020a00 0x1d0>,
>>>> - <0xd0021870 0x58>;
>>>> + <0xd0021070 0x58>;
>>>> };
>>>
>>> Hi Gregory
>>>
>>> Is this a bug fix needed for 3.7?
>>>
>>> Andrew
>>>
>> I don't think so.
>> We extended the reg map to be able to use registers only used for SMP.
>> When we didn't have SMP support the mapping was correct, and now by
>> introducing SMP we extend it.
>
> The length has stayed the same, so its not extended. Its now 0x800
> bytes earlier in the address space.
>
Right!
I didn't check it, sorry.
The correct explanation is that the offset +21070 is a CPU virtual offset.
That means that depending of the CPU core which will access to this register,
the controller will internally change the offset automagically to point the
correct offset.
I should have added an explanation in the commit log. I will do it for V2.
> Andrew
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 0/4] zynq subarch cleanups
From: Josh Cartwright @ 2012-10-22 21:10 UTC (permalink / raw)
To: linux-arm-kernel
Hey all-
Things have been relatively quiet on the Zynq front lately. This
patchset does a bit of cleanup of the Zynq subarchitecture. It was the
necessary set of things I had to do to get a zynq target booting with
the upstream qemu model. It removes some unused clock infrastructure,
adds DT support for the GIC, and moves around peripheral mappings.
On the CLKDEV_LOOKUP removal: the plan is to rework the out-of-tree
Xilinx generic clk support into something suitable for merging. What's
in tree now just isn't used at all, and can be removed.
Changes since v1:
- Make sure arm at kernel.org was included
- Rebased on arm-soc/for-next
- Added a cover letter
- Elaborated a bit on why I removed CLKDEV_LOOKUP
---
Josh Cartwright (4):
ARM: annotate VMALLOC_END definition with _AC
zynq: move static peripheral mappings
zynq: use GIC device tree bindings
zynq: remove use of CLKDEV_LOOKUP
arch/arm/Kconfig | 1 -
arch/arm/boot/dts/zynq-ep107.dts | 8 ++++---
arch/arm/include/asm/pgtable.h | 2 +-
arch/arm/mach-zynq/common.c | 16 ++++++++-----
arch/arm/mach-zynq/include/mach/clkdev.h | 32 --------------------------
arch/arm/mach-zynq/include/mach/zynq_soc.h | 36 ++++++++++++++++--------------
6 files changed, 35 insertions(+), 60 deletions(-)
delete mode 100644 arch/arm/mach-zynq/include/mach/clkdev.h
--
1.8.0
^ permalink raw reply
* [PATCH v3 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: Guennadi Liakhovetski @ 2012-10-22 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349791352-9829-1-git-send-email-fabio.estevam@freescale.com>
Hi Fabio
On Tue, 9 Oct 2012, Fabio Estevam wrote:
> Since mx27 transitioned to the commmon clock framework in 3.5, the correct way
> to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
>
> By not doing so the camera sensor does not probe correctly:
>
> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
> mx2-camera mx2-camera.0: Camera driver attached to camera 0
> ov2640 0-0030: Product ID error fb:fb
> mx2-camera mx2-camera.0: Camera driver detached from camera 0
> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 66500000
>
> Adapt the mx2_camera driver to the new clock framework and make it functional
> again.
>
> Tested-by: Ga?tan Carlier <gcembed@gmail.com>
> Tested-by: Javier Martin <javier.martin@vista-silicon.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
I've got a question to this your patch: could you explain to me, which
clock is obtained by
> + pcdev->clk_csi_per = devm_clk_get(&pdev->dev, "per");
? I don't find a clock named "per" and associated with "mx2-camera.0" in
arch/arm/mach-imx/clk-imx27.c. I only find it in clk-imx25.c. Does this
mean, that this your patch is for i.MX25? But you're saying it's for
i.MX27. Confused...
Thanks
Guennadi
> ---
> Changes since v2:
> - Fix clock error handling code as pointed out by Russell King
> Changes since v1:
> - Rebased against linux-next 20121008.
> drivers/media/platform/soc_camera/mx2_camera.c | 50 ++++++++++++++++++------
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c
> index 403d7f1..382b305 100644
> --- a/drivers/media/platform/soc_camera/mx2_camera.c
> +++ b/drivers/media/platform/soc_camera/mx2_camera.c
> @@ -272,7 +272,8 @@ struct mx2_camera_dev {
> struct device *dev;
> struct soc_camera_host soc_host;
> struct soc_camera_device *icd;
> - struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
> + struct clk *clk_emma_ahb, *clk_emma_ipg;
> + struct clk *clk_csi_ahb, *clk_csi_per;
>
> void __iomem *base_csi, *base_emma;
>
> @@ -432,7 +433,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
> {
> unsigned long flags;
>
> - clk_disable_unprepare(pcdev->clk_csi);
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> + clk_disable_unprepare(pcdev->clk_csi_per);
> writel(0, pcdev->base_csi + CSICR1);
> if (cpu_is_mx27()) {
> writel(0, pcdev->base_emma + PRP_CNTL);
> @@ -460,10 +462,14 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
> if (pcdev->icd)
> return -EBUSY;
>
> - ret = clk_prepare_enable(pcdev->clk_csi);
> + ret = clk_prepare_enable(pcdev->clk_csi_ahb);
> if (ret < 0)
> return ret;
>
> + ret = clk_prepare_enable(pcdev->clk_csi_per);
> + if (ret < 0)
> + goto exit_csi_ahb;
> +
> csicr1 = CSICR1_MCLKEN;
>
> if (cpu_is_mx27())
> @@ -480,6 +486,11 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
> icd->devnum);
>
> return 0;
> +
> +exit_csi_ahb:
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> +
> + return ret;
> }
>
> static void mx2_camera_remove_device(struct soc_camera_device *icd)
> @@ -1725,27 +1736,35 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
> goto exit;
> }
>
> - pcdev->clk_csi = devm_clk_get(&pdev->dev, "ahb");
> - if (IS_ERR(pcdev->clk_csi)) {
> - dev_err(&pdev->dev, "Could not get csi clock\n");
> - err = PTR_ERR(pcdev->clk_csi);
> + pcdev->clk_csi_ahb = devm_clk_get(&pdev->dev, "ahb");
> + if (IS_ERR(pcdev->clk_csi_ahb)) {
> + dev_err(&pdev->dev, "Could not get csi ahb clock\n");
> + err = PTR_ERR(pcdev->clk_csi_ahb);
> goto exit;
> }
>
> + pcdev->clk_csi_per = devm_clk_get(&pdev->dev, "per");
> + if (IS_ERR(pcdev->clk_csi_per)) {
> + dev_err(&pdev->dev, "Could not get csi per clock\n");
> + err = PTR_ERR(pcdev->clk_csi_per);
> + goto exit_csi_ahb;
> + }
> +
> pcdev->pdata = pdev->dev.platform_data;
> if (pcdev->pdata) {
> long rate;
>
> pcdev->platform_flags = pcdev->pdata->flags;
>
> - rate = clk_round_rate(pcdev->clk_csi, pcdev->pdata->clk * 2);
> + rate = clk_round_rate(pcdev->clk_csi_per,
> + pcdev->pdata->clk * 2);
> if (rate <= 0) {
> err = -ENODEV;
> - goto exit;
> + goto exit_csi_per;
> }
> - err = clk_set_rate(pcdev->clk_csi, rate);
> + err = clk_set_rate(pcdev->clk_csi_per, rate);
> if (err < 0)
> - goto exit;
> + goto exit_csi_per;
> }
>
> INIT_LIST_HEAD(&pcdev->capture);
> @@ -1801,7 +1820,7 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
> goto exit_free_emma;
>
> dev_info(&pdev->dev, "MX2 Camera (CSI) driver probed, clock frequency: %ld\n",
> - clk_get_rate(pcdev->clk_csi));
> + clk_get_rate(pcdev->clk_csi_per));
>
> return 0;
>
> @@ -1812,6 +1831,10 @@ eallocctx:
> clk_disable_unprepare(pcdev->clk_emma_ipg);
> clk_disable_unprepare(pcdev->clk_emma_ahb);
> }
> +exit_csi_per:
> + clk_disable_unprepare(pcdev->clk_csi_per);
> +exit_csi_ahb:
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> exit:
> return err;
> }
> @@ -1831,6 +1854,9 @@ static int __devexit mx2_camera_remove(struct platform_device *pdev)
> clk_disable_unprepare(pcdev->clk_emma_ahb);
> }
>
> + clk_disable_unprepare(pcdev->clk_csi_per);
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> +
> dev_info(&pdev->dev, "MX2 Camera driver unloaded\n");
>
> return 0;
> --
> 1.7.9.5
>
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH] ARM: imx: allow support to be disabled
From: Stephen Warren @ 2012-10-22 21:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Stephen Warren <swarren@nvidia.com>
Since ARCH_MXC's Kconfig option has no string name, the user is never
presented with an option to enable/disable this setting. Rather, it is
automatically enabled based on the conditions in the def_bool entry.
Add a string, so that the user gets to choose whether to enable ARCH_MXC,
and rename the i.MX options menu so that it doesn't clash. Also, change
from "def_bool y" to "bool" to be more consistent with other machines.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Note that if Tegra and i.MX support are enabled at the same time, then
the build will fail since both Tegra's and i.MX's head.S define symbol
v7_invalidate_l1. shmobile appears to have the same conflict. Note that
patches to port Tegra to ARCH_MULTI aren't yet in linux-next, but I can
point anyone who's interested at my github tree.
---
arch/arm/mach-imx/Kconfig | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 892631f..5cc2417 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -1,5 +1,5 @@
config ARCH_MXC
- def_bool y if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
+ bool "Freescale i.MX support" if ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7
select ARCH_REQUIRE_GPIOLIB
select ARM_PATCH_PHYS_VIRT
select AUTO_ZRELADDR if !ZBOOT_ROM
@@ -13,7 +13,7 @@ config ARCH_MXC
help
Support for Freescale MXC/iMX-based family of processors
-menu "Freescale i.MX support"
+menu "Freescale i.MX options"
depends on ARCH_MXC
config MXC_IRQ_PRIOR
--
1.7.0.4
^ permalink raw reply related
* [PATCH 6/7] crypto: omap-sham: Add code to use dmaengine API
From: Mark A. Greer @ 2012-10-22 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALLzPKbacnyQ=ZTzT+XMVcsxy4m_EdZgv7sZaWJFUwym4AndpA@mail.gmail.com>
On Sun, Oct 21, 2012 at 02:52:13PM +0300, Kasatkin, Dmitry wrote:
> Hello,
>
> I got only 3 patches out of 7.
> Can you please re-submit them also to linux-crypto at vger.kernel.org
> That is a list where crypto drivers are discussed.
Okay, I will CC you and the linux-crypto on the entire series when
I submit v2.
Sorry about that.
Mark
--
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-10-22 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87objufl68.fsf@deeprootsystems.com>
Kevin Hilman <khilman@deeprootsystems.com> writes:
> Paul Walmsley <paul@pwsan.com> writes:
>
>> Hi Kevin
>>
>> On Fri, 19 Oct 2012, Paul Walmsley wrote:
>>
>>> On Thu, 18 Oct 2012, Paul Walmsley wrote:
>>>
>>> > Here are some basic OMAP test results for Linux v3.7-rc1.
>>> > Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/
>>
>> ...
>>
>>> > Failing tests: needing investigation
>>> > ------------------------------------
>>> >
>>
>> ...
>>
>>> > PM tests:
>>>
>>> * 3730 Beagle XM: OPPs do not initialize
>>> - Several "find_device_opp: Invalid parameters" messages appear on boot;
>>> related warnings follow
>>> - Cause unknown
>>
>> This one seems to be caused by this commit:
>>
>> commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64
>> Author: Kevin Hilman <khilman@ti.com>
>> Date: Thu Sep 6 14:03:08 2012 -0700
>>
>> ARM: OMAP2+: PM: MPU DVFS: use generic CPU device for MPU-SS
>>
>> Care to take a look at it and fix it?
>>
>
> Yup, will fix. Looks like this exposed some initcall ordering issues in
> the Beagle board file when adding OPPs.
Here's the fix:
http://marc.info/?l=linux-omap&m=135093801330065&w=2
I'll be adding this to my PM-related fixes queue for v3.7-rc3.
Kevin
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-10-22 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y5iyfmmo.fsf@deeprootsystems.com>
Kevin Hilman <khilman@deeprootsystems.com> writes:
> Aaro Koskinen <aaro.koskinen@iki.fi> writes:
>
>> Hi,
>>
>> On Fri, Oct 19, 2012 at 10:01:36PM +0300, Felipe Balbi wrote:
>>> On Fri, Oct 19, 2012 at 10:03:58PM +0300, Aaro Koskinen wrote:
>>> > FYI, I saw I2C hangs also on Nokia N900 with v3.7-rc1 (omap_i2c
>>> > omap_i2c.1: timeout waiting for bus ready). After several reboots they
>>> > disappered (kernel binary was the same), and I have been unable to
>>> > reproduce them since.
>>>
>>> any change you have those logs saved somewhere ? Want to see if it's the
>>> same problem triggered by RTC.
>>
>> I did not save the logs, but now I tried again, I managed to reproduce
>> it after couple boots. The log is below, and after that the there's also
>> one from OK boot for comparison.
>>
>> In the error case, the boot never reaches userspace, just silently hangs
>> (or maybe I just didn't wait enough long).
>
> Can you try to revert the threaded IRQ conversion to see if things get
> to working again? commit 3b2f8f82dad7d1f79cdc8fc05bd1c94baf109bde
Nevermind, Paul seems to have already isolated the problem on this one.
Kevin
^ permalink raw reply
* [PATCH] ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio
From: Tony Lindgren @ 2012-10-22 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508530CE.9000703@ti.com>
* P?ter Ujfalusi <peter.ujfalusi@ti.com> [121022 04:42]:
> Hi Tony,
>
> On 10/18/2012 12:00 PM, Benoit Cousson wrote:
> > On 10/18/2012 11:25 AM, Peter Ujfalusi wrote:
> >> Fixes the following errors:
> >> [ 2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
> >> [ 2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel
> >>
> >> Which is because we failed to link the sidetone hwmod for McBSP2/3. The
> >> missing sidetone hwmod link will prevent omap_device_alloc() to append the
> >> DMA resources since we - accidentally - end up having the same number of
> >> resources provided from DT (IO/IRQ) as we have in hwmod for the McBSP ports
> >> without the ST resources.
> >>
> >> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> >
> > Acked-by: Benoit Cousson <b-cousson@ti.com>
>
> Can you take this patch for -rc3?
Thanks will apply into omap-for-v3.7-rc2/fixes.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/2] ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals.
From: Tony Lindgren @ 2012-10-22 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022203324.22746.54210.stgit@muffinssi.local>
On n900 uart1 pins are not not used for uart, instead they are
used to connect to a cell modem over ssi. Looks like we're
currently missing these signal names for 3430 for some reason,
and only have some of them listed for 3630. Obviously the signals
are there for 3430 if n900 is using them and they are documented
in some TRMs.
Note that these will eventually be replaced by device tree
based pinctrl-single.c driver. But for now these are needed
to verify the SSI pins for devices like Nokia N900.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
0 files changed
diff --git a/arch/arm/mach-omap2/mux34xx.c b/arch/arm/mach-omap2/mux34xx.c
index 17f80e4..c47140b 100644
--- a/arch/arm/mach-omap2/mux34xx.c
+++ b/arch/arm/mach-omap2/mux34xx.c
@@ -614,16 +614,16 @@ static struct omap_mux __initdata omap3_muxmodes[] = {
"sys_off_mode", NULL, NULL, NULL,
"gpio_9", NULL, NULL, "safe_mode"),
_OMAP3_MUXENTRY(UART1_CTS, 150,
- "uart1_cts", NULL, NULL, NULL,
+ "uart1_cts", "ssi1_rdy_tx", NULL, NULL,
"gpio_150", "hsusb3_tll_clk", NULL, "safe_mode"),
_OMAP3_MUXENTRY(UART1_RTS, 149,
- "uart1_rts", NULL, NULL, NULL,
+ "uart1_rts", "ssi1_flag_tx", NULL, NULL,
"gpio_149", NULL, NULL, "safe_mode"),
_OMAP3_MUXENTRY(UART1_RX, 151,
- "uart1_rx", NULL, "mcbsp1_clkr", "mcspi4_clk",
+ "uart1_rx", "ss1_wake_tx", "mcbsp1_clkr", "mcspi4_clk",
"gpio_151", NULL, NULL, "safe_mode"),
_OMAP3_MUXENTRY(UART1_TX, 148,
- "uart1_tx", NULL, NULL, NULL,
+ "uart1_tx", "ssi1_dat_tx", NULL, NULL,
"gpio_148", NULL, NULL, "safe_mode"),
_OMAP3_MUXENTRY(UART2_CTS, 144,
"uart2_cts", "mcbsp3_dx", "gpt9_pwm_evt", NULL,
^ permalink raw reply related
* [PATCH 1/2] ARM: OMAP2+: Fix location of select PINCTRL
From: Tony Lindgren @ 2012-10-22 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121022203324.22746.54210.stgit@muffinssi.local>
Commit 8f31cefe (ARM: OMAP2+: select PINCTRL in Kconfig)
added select PINCTRL, but accdentally added it to a wrong
location.
We want to select if for ARCH_OMAP2PLUS, not for
ARCH_OMAP2PLUS_TYPICAL.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
0 files changed
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2a1a898..d669e22 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -11,7 +11,6 @@ config ARCH_OMAP2PLUS_TYPICAL
select I2C_OMAP
select MENELAUS if ARCH_OMAP2
select NEON if ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5
- select PINCTRL
select PM_RUNTIME
select REGULATOR
select SERIAL_OMAP
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 7cd56ed..82fcb20 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -26,6 +26,7 @@ config ARCH_OMAP2PLUS
select CLKDEV_LOOKUP
select GENERIC_IRQ_CHIP
select OMAP_DM_TIMER
+ select PINCTRL
select PROC_DEVICETREE if PROC_FS
select SPARSE_IRQ
select USE_OF
^ permalink raw reply related
* [PATCH 0/2] few omap mux fixes for v3.7-rc2
From: Tony Lindgren @ 2012-10-22 20:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I noticed these two issues while testing some pinctrl
related changes.
Regards,
Tony
---
Tony Lindgren (2):
ARM: OMAP2+: Fix location of select PINCTRL
ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals.
0 files changed
--
Signature
^ permalink raw reply
* [PATCH] ARM: OMAP3: Beagle: fix OPP customization and initcall ordering
From: Kevin Hilman @ 2012-10-22 20:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
After commit 24d7b40a60cf19008334bcbcbd98da374d4d9c64 (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.
First, fix the board file to use get_cpu_device() as required by the
above commit, otherwise custom OPPs will be added to the wrong device.
Second, the board files OPP init is called from the its init_machine
method, and the generic CPU devices are not yet created when
init_machine is run. Therefore OPP initialization will fail. To fix,
use a device_initcall() for the board file's OPP customization.
Reported-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
---
Tony, unless there are objections, I'll add this to a series of
PM related fixes I have left for v3.7-rc.
arch/arm/mach-omap2/board-omap3beagle.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 388c431..befad2a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -24,6 +24,7 @@
#include <linux/input.h>
#include <linux/gpio_keys.h>
#include <linux/opp.h>
+#include <linux/cpu.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
@@ -444,12 +445,13 @@ static struct omap_board_mux board_mux[] __initdata = {
};
#endif
-static void __init beagle_opp_init(void)
+static int __init beagle_opp_init(void)
{
int r = 0;
- /* Initialize the omap3 opp table */
- if (omap3_opp_init()) {
+ /* Initialize the omap3 opp table if not already created. */
+ r = omap3_opp_init();
+ if (IS_ERR_VALUE(r) && (r != -EEXIST)) {
pr_err("%s: opp default init failed\n", __func__);
return;
}
@@ -458,13 +460,13 @@ static void __init beagle_opp_init(void)
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
- mpu_dev = omap_device_get_by_hwmod_name("mpu");
+ mpu_dev = get_cpu_device(0);
iva_dev = omap_device_get_by_hwmod_name("iva");
if (IS_ERR(mpu_dev) || IS_ERR(iva_dev)) {
pr_err("%s: Aiee.. no mpu/dsp devices? %p %p\n",
__func__, mpu_dev, iva_dev);
- return;
+ return -ENODEV;
}
/* Enable MPU 1GHz and lower opps */
r = opp_enable(mpu_dev, 800000000);
@@ -484,8 +486,9 @@ static void __init beagle_opp_init(void)
opp_disable(iva_dev, 660000000);
}
}
- return;
+ return 0;
}
+device_initcall(beagle_opp_init);
static void __init omap3_beagle_init(void)
{
@@ -522,8 +525,6 @@ static void __init omap3_beagle_init(void)
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
-
- beagle_opp_init();
}
MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
--
1.8.0
^ permalink raw reply related
* [PATCH v2] pinctrl: reserve pins when states are activated
From: Stephen Warren @ 2012-10-22 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZazjMoSzkr5t15-GeCnQKCJDsZyvT=KVMyw5XhjDybGQ@mail.gmail.com>
On 10/22/2012 02:21 AM, Linus Walleij wrote:
> On Fri, Oct 19, 2012 at 8:10 PM, Tony Lindgren <tony@atomide.com> wrote:
>> [Me]
>>> Instead: let use reserve the pins when the state is activated
>>> and drop them when the state is disabled, i.e. when we move to
>>> another state. This way different devices/functions can use the
>>> same pins at different times.
>>
>> Hmm doesn't this mean that we are now doing lots of extra
>> reserving and dropping of pins? Performance is important from
>> latency point of view for cases where we need to remux pins
>> constantly runtime PM.
>
> It is only done in case the pinmux state is switched in runtime
> suspend/resume, so it's e.g. possible to just alter the pin config.
>
> But in general what you say is true.
>
> We used to to the same thing by having drivers call
> pinctrl_get()/pinctrl_put() in this case instead, but that went
> away with the introduction of states, so we cannot encode
> different pin sets with say
> pinctrl_get(dev, "foo")/pinctrl_get(dev, "bar")
> anymore since there is only one pinctrl handle per device,
> but multiple states.
>
> If this turns out to be a severe performance bottleneck, I
> suggest to add some additional constraint API, like
> pinctrl_set_pinmux_homegeneous_pinsets(true) that will
> at runtime select whether the pin allocation is done when
> getting the pinctrl handle instead.
That API sounds like something system-wide, which seems like it would be
rather presumptuous (CPU/SoC support code couldn't execute it, since
that would presume a facet of all board designs that could change in the
future). Even a driver shouldn't be assuming this; it can't know what
boards it gets used in ahead of time.
Instead, it seems like the map registration code could easily look at
all states defined for a device, and determine if the set of pins/groups
used by those states was identical, and switch between up-front or
dynamic registration as needed by the specific map entries.
^ permalink raw reply
* [PATCH v2 2/9] pinctrl: single: support gpio request and free
From: Tony Lindgren @ 2012-10-22 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350922139-3693-3-git-send-email-haojian.zhuang@gmail.com>
* Haojian Zhuang <haojian.zhuang@gmail.com> [121022 09:11]:
> Marvell's PXA/MMP silicon also match the behavior of pinctrl-single.
> Each pin binds to one register. A lot of pins could be configured
> as gpio.
>
> Now add three properties in below.
> pinctrl-single,gpio-ranges: gpio range array
> pinctrl-single,gpio: <gpio base, npins in range, pin base in range>
> pinctrl-single,gpio-func: <gpio function value in mux>
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
> ---
> drivers/pinctrl/pinctrl-single.c | 94 +++++++++++++++++++++++++++++++++++++-
> 1 files changed, 92 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index 726a729..6a0b24b 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -28,8 +28,10 @@
> #define DRIVER_NAME "pinctrl-single"
> #define PCS_MUX_PINS_NAME "pinctrl-single,pins"
> #define PCS_MUX_BITS_NAME "pinctrl-single,bits"
> +#define PCS_GPIO_FUNC_NAME "pinctrl-single,gpio-func"
I think we can now get rid of these defines, I initially added
them as we had a bit hard time finding a suitable name for the
driver. These are only used in one location, so let's not add
new ones here.
> static int pcs_request_gpio(struct pinctrl_dev *pctldev,
> - struct pinctrl_gpio_range *range, unsigned offset)
> + struct pinctrl_gpio_range *range, unsigned pin)
> {
> - return -ENOTSUPP;
> + struct pcs_device *pcs = pinctrl_dev_get_drvdata(pctldev);
> + struct pcs_gpio_range *gpio = NULL;
> + int end, mux_bytes;
> + unsigned data;
> +
> + gpio = container_of(range, struct pcs_gpio_range, range);
> + if (!gpio->func_en)
> + return 0;
> + end = range->pin_base + range->npins - 1;
> + if (pin < range->pin_base || pin > end) {
> + dev_err(pctldev->dev, "pin %d isn't in the range of "
> + "%d to %d\n", pin, range->pin_base, end);
> + return -EINVAL;
> + }
> + mux_bytes = pcs->width / BITS_PER_BYTE;
> + data = pcs_readl(pcs->base + pin * mux_bytes) & ~pcs->fmask;
> + data |= gpio->gpio_func;
> + pcs_writel(data, pcs->base + pin * mux_bytes);
> + return 0;
> }
I think I already commented on this one.. Is this safe if you don't
have GPIOs configured? Or should you return -ENODEV in that case?
> +static int __devinit pcs_add_gpio_range(struct device_node *node,
> + struct pcs_device *pcs)
> +{
> + struct pcs_gpio_range *gpio;
> + struct device_node *np;
> + const __be32 *list;
> + const char list_name[] = "pinctrl-single,gpio-ranges";
> + const char name[] = "pinctrl-single";
> + u32 gpiores[PCS_MAX_GPIO_VALUES];
> + int ret, size, i, mux_bytes = 0;
> +
> + list = of_get_property(node, list_name, &size);
> + if (!list)
> + return -ENOENT;
Here you should return 0 if not found, otherwise things go bad for
me at least as I don't have GPIOs configured. See more below.
> + gpio->range.name = kmemdup(name, sizeof(name), GFP_KERNEL);
> + pinctrl_add_gpio_range(pcs->pctl, &gpio->range);
Just checking.. These get released with pinctrl_unregister() when
unloading, right? And nothing else to free in pinctrl-single.c
either?
> @@ -975,6 +1061,10 @@ static int __devinit pcs_probe(struct platform_device *pdev)
> goto free;
> }
>
> + ret = pcs_add_gpio_range(np, pcs);
> + if (ret < 0)
> + return ret;
> +
Here you need to goto free on error. Maybe just fold in the
attached fix if that looks OK to you:
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -930,7 +930,7 @@ static int __devinit pcs_add_gpio_range(struct device_node *node,
list = of_get_property(node, list_name, &size);
if (!list)
- return -ENOENT;
+ return 0;
size = size / sizeof(*list);
for (i = 0; i < size; i++) {
np = of_parse_phandle(node, list_name, i);
@@ -1065,7 +1065,7 @@ static int __devinit pcs_probe(struct platform_device *pdev)
ret = pcs_add_gpio_range(np, pcs);
if (ret < 0)
- return ret;
+ goto free;
dev_info(pcs->dev, "%i pins at pa %p size %u\n",
pcs->desc.npins, pcs->base, pcs->size);
^ permalink raw reply
* [PATCH 03/10] tty: pxa: configure pin
From: Stephen Warren @ 2012-10-22 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb5Jiw71jBLDXpf2VTJQx7_gABqs03_20CeCLbVT=JkaA@mail.gmail.com>
On 10/22/2012 02:45 AM, Linus Walleij wrote:
> On Fri, Oct 19, 2012 at 12:20 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
>> On 10/18/2012 03:06 AM, Haojian Zhuang wrote:
>>> Configure pins by pinctrl driver.
>>
>> In general, it seems better to use pinctrl "hogs" if the driver is only
>> going to statically set up one pinctrl state and never change it. The
>> alternative is make every single driver execute these pinctrl calls,
>> which could be tedious.
>
> True. And each platform has to choose how to go ahead with this.
>
> I always imagined that any system of the "power socket in wall"
> type would just use hogs to configure its pins and be done with
> it, and there appear to be some platforms like that. (e.g. MIPS and
> various power-inaware references come to mind).
>
> For the Ux500 drivers we have found that all of those that have pin
> resources actually have to be handled by the driver. The reason is
> that all of them have idle and/or sleep states that need to be
> handled at runtime.
Well, presumably the pinctrl driver itself could have both default/idle
states, and system sleep could engage the appropriate system-wide setting.
> As an additional complication our drivers are used also by
> the Versatile and SPEAr family of platforms, so the control
> need to be tolerant (accept missing pinctrl handles and states)
> as well. (I can see that other drivers take shortcuts by being less
> elaborate since there is a 1:1 driver<->platform mapping.)
Isn't the driver (or DT binding) supposed to define what pinctrl states
must exist, and those state must always exist? There's no requirement
for a pinctrl state definition to always actually contain content that
changes the state. That's exactly why PIN_MAP_TYPE_DUMMY_STATE exists.
> An alternative to embedding the pin handling code into
> the drivers is to use bus notifiers as is done with the
> shmobile clocking by drivers/base/power/clock_ops.c
> I could easily imagine pinctrl_ops.c like that for some
> platforms. This mandates still binding the pin table entries
> to a device but avoids adding any code to the drivers.
>
> However this latter approach does not work for us (Ux500) -
> the three resources we have: clocks, pins and power domains
> are dependent on state switch ordering (sometimes you need
> to switch off the clock then set pin state, sometimes the
> other way around) and it is not even
> the same for all drivers - the notifier approach mandates
> that all drivers do the clock, power domain and pin handling
> uniformly.
That certainly does imply that individual drivers do need to handle this
explicitly. Although I still think that only specific drivers actually
affected by this should end up actively managing pinctrl; shouldn't
anything that can get away with relying on system hogs do so?
^ permalink raw reply
* [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
From: Stephen Warren @ 2012-10-22 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350910413-23925-2-git-send-email-maxime.ripard@free-electrons.com>
On 10/22/2012 06:53 AM, Maxime Ripard wrote:
> Allow the i2c-mux-gpio to be used by a device tree enabled device. The
> bindings are inspired by the one found in the i2c-mux-pinctrl driver.
Reviewed-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* [PATCH] pinctrl: reserve pins when states are activated
From: Stephen Warren @ 2012-10-22 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350893718-12336-1-git-send-email-linus.walleij@stericsson.com>
On 10/22/2012 02:15 AM, Linus Walleij wrote:
> This switches the way that pins are reserved for multiplexing:
>
> We used to do this when the map was parsed, at the creation of
> the settings inside the pinctrl handle, in pinmux_map_to_setting().
>
> However this does not work for us, because we want to use the
> same set of pins with different devices at different times: the
> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
> void pinmux_free_setting(struct pinctrl_setting const *setting)
...
> + /* This function is currently unused */
Being picky: It's not unused; it is used by pinctrl_put_locked(), but
just doesn't have to do anything given the implementation of
pinmux_map_to_setting().
^ permalink raw reply
* [PATCH] pinctrl/nomadik: use irq_create_mapping()
From: Stephen Warren @ 2012-10-22 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbcTT_Mfa67Vw_6Y3RvqOE3CMA7kNXLG5oja0uTNn1FoA@mail.gmail.com>
On 10/22/2012 02:14 AM, Linus Walleij wrote:
> On Fri, Oct 19, 2012 at 6:22 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 10/19/2012 09:09 AM, Linus Walleij wrote:
>>> From: Linus Walleij <linus.walleij@linaro.org>
>>
>>> @@ -931,7 +931,7 @@ static void __nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc,
>>> while (status) {
>>> int bit = __ffs(status);
>>>
>>> - generic_handle_irq(irq_find_mapping(nmk_chip->domain, bit));
>>> + generic_handle_irq(irq_create_mapping(nmk_chip->domain, bit));
>>
>> Surely this one can remain as irq_find_mapping() since isn't
>> nmk_gpio_to_irq() guaranteed to have been called first for this GPIO/IRQ?
>
> It's an IRQ handler so it should be robust to spurious IRQs due to
> transient hardware states etc I believe.
>
> So if there is a transient IRQ before gpio_to_irq() is called -> boom.
I wonder though (a) why it would be unmasked in HW, and (b) why the
software would even look at the status bit if no handler were registered?
^ permalink raw reply
* [PATCH 3/5] arm: mvebu: Added IPI support via doorbells
From: Andrew Lunn @ 2012-10-22 20:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50859976.6080601@free-electrons.com>
On Mon, Oct 22, 2012 at 09:07:34PM +0200, Gregory CLEMENT wrote:
> On 10/22/2012 07:30 PM, Andrew Lunn wrote:
> > On Mon, Oct 22, 2012 at 07:02:45PM +0200, Gregory CLEMENT wrote:
> >> From: Yehuda Yitschak <yehuday@marvell.com>
> >>
> >> Signed-off-by: Yehuda Yitschak <yehuday@marvell.com>
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >> ---
> >> arch/arm/boot/dts/armada-xp.dtsi | 2 +-
> >> arch/arm/mach-mvebu/armada-370-xp.h | 10 ++++
> >> arch/arm/mach-mvebu/irq-armada-370-xp.c | 92 +++++++++++++++++++++++++++++--
> >> 3 files changed, 97 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> >> index f521ed8..531619f 100644
> >> --- a/arch/arm/boot/dts/armada-xp.dtsi
> >> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> >> @@ -24,7 +24,7 @@
> >>
> >> mpic: interrupt-controller at d0020000 {
> >> reg = <0xd0020a00 0x1d0>,
> >> - <0xd0021870 0x58>;
> >> + <0xd0021070 0x58>;
> >> };
> >
> > Hi Gregory
> >
> > Is this a bug fix needed for 3.7?
> >
> > Andrew
> >
> I don't think so.
> We extended the reg map to be able to use registers only used for SMP.
> When we didn't have SMP support the mapping was correct, and now by
> introducing SMP we extend it.
The length has stayed the same, so its not extended. Its now 0x800
bytes earlier in the address space.
Andrew
^ permalink raw reply
* [PATCH 2/7] ARM: OMAP2xxx: hwmod: Add DMA information for SHAM module
From: Mark A. Greer @ 2012-10-22 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210221950330.13464@utopia.booyaka.com>
On Mon, Oct 22, 2012 at 07:53:06PM +0000, Paul Walmsley wrote:
> On Mon, 22 Oct 2012, Mark A. Greer wrote:
>
> > On Sat, Oct 20, 2012 at 07:40:44PM +0000, Paul Walmsley wrote:
> > > On Fri, 19 Oct 2012, Mark A. Greer wrote:
> > >
> > > > From: "Mark A. Greer" <mgreer@animalcreek.com>
> > > >
> > > > Add the DMA information for the OMAP2 SHA module.
> > > >
> > > > CC: Paul Walmsley <paul@pwsan.com>
> > > > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> > >
> > > This can probably be combined with the first patch.
> >
> > I made it a separate patch because the original omap2xxx code didn't
> > support DMA and I wanted to keep the first patch an apples-apples
> > conversion and _add_ functionality in this, separate, patch.
> >
> > I prefer 2 patches but if you still want me to combine them, let me know.
>
> OK, I see. That's fine, then. Maybe add a sentence about that into the
> patch description of #2, that this effectively enables a code path in
> the driver that wasn't being used before, and therefore should be in a
> separate patch for ease of bisecting?
Sure. After your comment I realized my description was insufficient.
Mark
--
^ 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