Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Dmitry Torokhov @ 2012-10-22 15:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350911580-20307-1-git-send-email-sourav.poddar@ti.com>

Hi Sourav,

On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote:
> Adapt keypad to use pinctrl framework.
> 
> Tested on omap4430 sdp with 3.7-rc1 kernel.

I do not see anything in the driver that would directly use pinctrl. Is
there a better place to select default pin configuration; maybe when
instantiating platform device?

Thanks.

> 
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
> ---
> v1->v2
> - Added "PROBE_DEFER" check 
>  drivers/input/keyboard/omap4-keypad.c |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> index c05f98c..502b832 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -31,6 +31,7 @@
>  #include <linux/input.h>
>  #include <linux/slab.h>
>  #include <linux/pm_runtime.h>
> +#include <linux/pinctrl/consumer.h>
>  
>  #include <linux/platform_data/omap4-keypad.h>
>  
> @@ -76,6 +77,7 @@ enum {
>  
>  struct omap4_keypad {
>  	struct input_dev *input;
> +	struct pinctrl	*pins;
>  
>  	void __iomem *base;
>  	unsigned int irq;
> @@ -298,6 +300,15 @@ static int __devinit omap4_keypad_probe(struct platform_device *pdev)
>  		goto err_release_mem;
>  	}
>  
> +	keypad_data->pins = devm_pinctrl_get_select_default(&pdev->dev);
> +	if (IS_ERR(keypad_data->pins)) {
> +		if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER)
> +			return -EPROBE_DEFER;
> +
> +		dev_warn(&pdev->dev, "did not get pins for keypad error: %li\n",
> +					PTR_ERR(keypad_data->pins));
> +		keypad_data->pins = NULL;
> +	}
>  
>  	/*
>  	 * Enable clocks for the keypad module so that we can read
> -- 
> 1.7.1
> 

-- 
Dmitry

^ permalink raw reply

* [PATCH 4/4] zynq: move static peripheral mappings
From: Josh Cartwright @ 2012-10-22 15:37 UTC (permalink / raw)
  To: linux-arm-kernel

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 | 34 +++++++++++++++++-------------
 2 files changed, 23 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 6ea86cf..e10268c 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -75,17 +75,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,
 	},
 
@@ -93,7 +93,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 3d1c6a6..9156914 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -15,31 +15,35 @@
 #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 PL310_L2CC_BASE			IOMEM(PL310_L2CC_VIRT)
+#define TTC0_BASE		IOMEM(TTC0_VIRT)
+#define SCU_PERIPH_BASE		IOMEM(SCU_PERIPH_VIRT)
+#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 3/4] zynq: remove use of CLKDEV_LOOKUP
From: Josh Cartwright @ 2012-10-22 15:37 UTC (permalink / raw)
  To: linux-arm-kernel

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.

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 73067ef..e37bea3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -959,7 +959,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 d73963b..6ea86cf 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 2/4] zynq: use GIC device tree bindings
From: Josh Cartwright @ 2012-10-22 15:37 UTC (permalink / raw)
  To: linux-arm-kernel

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 ab5cfdd..d73963b 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 d0d3f8f..3d1c6a6 100644
--- a/arch/arm/mach-zynq/include/mach/zynq_soc.h
+++ b/arch/arm/mach-zynq/include/mach/zynq_soc.h
@@ -35,8 +35,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)
 
 /*
-- 
1.8.0

^ permalink raw reply related

* [PATCH 1/4] ARM: annotate VMALLOC_END definition with _AC
From: Josh Cartwright @ 2012-10-22 15:37 UTC (permalink / raw)
  To: linux-arm-kernel

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 0/4] ARM/dts: Update OMAP5 with address space and interrupts
From: Sebastien Guiriec @ 2012-10-22 15:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5085541C.5040209@ti.com>

Hi Benoit,

On 10/22/2012 04:11 PM, Benoit Cousson wrote:
> Hi Seb,
>
> Good work. Thanks for that series.
>
> Just update it with all the acked-by you've got from the TI driver folks
> + the minor comment and I'll pull it in the for_3.8/dts branch.
>
> That's a detail but you should update the subject with "ARM: dts: OMAP5:
> XXX" prefix for consistency with the latest naming convention.
Thanks for the information I will update the series. I was thinking that 
it was the convention according to a past talk. I will update our full 
audio/display feature tree with this convention.

>
> Please, Cc the DT list as well.
>
> Regards,
> Benoit
>
> On 10/22/2012 12:22 PM, Sebastien Guiriec wrote:
>> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space
>> and interrupt line description inside dtsi file for OMAP5. This serie is updating the
>> current OMAP5 IP with missing entry.
>>
>> It has been tested on OMAP5 with 3.7-audio-display feature tree.
>> - MMC is probing and functional
>> - TWL6041 probing (GPIO/I2C)
>> - booting (UART)
>>
>> Sebastien Guiriec (4):
>>    ARM/dts: omap5: Update GPIO with address space and interrupt
>>    ARM/dts: omap5: Update I2C with address space and interrupts
>>    ARM/dts: omap5: Update UART with address space and interrupts
>>    ARM/dts: omap5: Update MMC with address space and interrupts
>>
>>   arch/arm/boot/dts/omap5.dtsi |   56 +++++++++++++++++++++++++++++++++++++++---
>>   1 file changed, 52 insertions(+), 4 deletions(-)
>>
>

^ permalink raw reply

* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Thierry Reding @ 2012-10-22 15:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201210221352.08352.arnd@arndb.de>

On Mon, Oct 22, 2012 at 01:52:08PM +0000, Arnd Bergmann wrote:
> On Monday 22 October 2012, Thierry Reding wrote:
> > > As long as we get build warnings for leaving out the __devinit/__devexit
> > > annotations, I would generally recommend putting them in. If we do a
> > > patch to remove all of them, a couple extra instances will not cause
> > > any more troubles than we already have.
> > 
> > I've never seen any build warnings for leaving __devinit/__devexit out.
> > Where does that happen?
> 
> Section mismatches usually result into warnings from modpost, like
> 
> WARNING: modpost: Found 1 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
> 
> Actually doing that gives you an output like this (currently on exynos_defconfig):
> 
> $ make CONFIG_DEBUG_SECTION_MISMATCH=y
> WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
> The function __devinit samsung_pinctrl_probe() references
> a function __init samsung_gpiolib_register().
> If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
> annotate samsung_gpiolib_register with a matching annotation.
> 
> or like this (now fixed in socfpga_defconfig):
> 
> WARNING: drivers/net/ethernet/stmicro/stmmac/stmmac.o(.text+0x5d4c): Section mismatch in reference from the function stmmac_pltfr_probe() to the function .devinit.text:stmmac_probe_config_dt()
> The function stmmac_pltfr_probe() references
> the function __devinit stmmac_probe_config_dt().
> This is often because stmmac_pltfr_probe lacks a __devinit 
> annotation or the annotation of stmmac_probe_config_dt is wrong.
> 
> I believe you normally don't get warnings for functions that could be
> marked __devinit and only call regular functions, but there are
> a couple of __devinit infrastructure functions that you can't call
> from a function that isn't __init or __devinit.

Right. If you get those warnings you shouldn't be dropping the
annotations. But I don't think that is the case for this driver. Tony,
can you confirm that the driver still builds properly without warnings
if you drop the __devinit/__devexit?

Thierry
-------------- 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/20121022/6cdc3372/attachment.sig>

^ permalink raw reply

* [PATCH 0/8] I2C patches for v3.8 merge window
From: Shubhrajyoti @ 2012-10-22 15:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121022140658.GA18993@arwen.pp.htv.fi>

On Monday 22 October 2012 07:36 PM, Felipe Balbi wrote:
> can you also check if echo mem > /sys/power/state works ? Don't forget
> to enable UART wakeups with:
>
> echo enabled > /sys/devices/platform/omap_uart.2/power/wakeup
> echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
>
> before trying to suspend. Another cool test is rtctest (since our RTC is
> part of TWL). It worked fine on my two platforms. Attached you will find
> the sourcecode for rtctest.
On omap3 tested . with off hitting both in suspend and idle path.


Also with rtcwake.

Thanks

^ permalink raw reply

* [PATCH v4] ARM: SMP_TWD: make setup()/stop() reentrant
From: Shawn Guo @ 2012-10-22 14:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350911721-3184-1-git-send-email-linus.walleij@stericsson.com>

On Mon, Oct 22, 2012 at 03:15:21PM +0200, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
> 
> It has been brought to my knowledge that the .setup()/.stop()
> function pair in the SMP TWD is going to be called from atomic
> contexts for CPUs coming and going, and then the
> clk_prepare()/clk_unprepare() calls cannot be called
> on subsequent .setup()/.stop() iterations. This is however
> just the tip of an iceberg as the function pair is not
> designed to be reentrant at all.
> 
> This change makes the SMP_TWD clock .setup()/.stop() pair reentrant
> by splitting the .setup() function in three parts:
> 
> - One COMMON part that is executed the first time the first CPU
>   in the TWD cluster is initialized. This will fetch the TWD
>   clk for the cluster and prepare+enable it. If no clk is
>   available it will calibrate the rate instead.
> 
> - One part that is executed the FIRST TIME a certain CPU is
>   brought on-line. This initializes and sets up the clock event
>   for a certain CPU.
> 
> - One part that is executed on every subsequent .setup() call.
>   This will re-initialize the clock event. This is augmented
>   to call the clk_enable()/clk_disable() pair properly.
> 
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Reported-by: Peter Chen <peter.chen@freescale.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Tested-by: Shawn Guo <shawn.guo@linaro.org>

^ permalink raw reply

* [PATCH v2] ARM: SMP_TWD: make setup()/stop() reentrant
From: Shawn Guo @ 2012-10-22 14:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdbpDQQKm2=3zued=Kf2ykiVpb9wQDrSZf7=k8h1ryLAgA@mail.gmail.com>

On Mon, Oct 22, 2012 at 12:14:03PM +0200, Linus Walleij wrote:
> > 2. When secondary cores get off-line, the clockevent devices for
> >    the cores will be released.  So when they become online, the
> >    clockevent devices should be registered again.
> 
> So that is how it happens. Where is the code releasing all
> clock events? I was thinking this would more properly be done
> in the .stop() path of the SMP TWD driver?
> 
tick_notify() will receive CLOCK_EVT_NOTIFY_CPU_DEAD when a cpu goes
away.  It results in tick_shutdown() invoking which will release the
clockevent device for the cpu.

Shawn

^ permalink raw reply

* [GIT PULL] Renesas ARM-based SoC defconfig for v3.8
From: Arnd Bergmann @ 2012-10-22 14:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121022015126.GA10587@verge.net.au>

(adding Nico, who did a lot of the work to get rid of PLAT_PHYS_OFFSET)

On Monday 22 October 2012, Simon Horman wrote:
> On Mon, Oct 22, 2012 at 09:33:51AM +0900, Simon Horman wrote:
> > On Fri, Oct 19, 2012 at 08:18:50AM +0000, Arnd Bergmann wrote:
> > > On Friday 19 October 2012, Simon Horman wrote:
> > > > * A more significant problem seems to be the use of CONFIG_MEMORY_START
> > > >   to define PLAT_PHYS_OFFSET in arch/arm/mach-shmobile/include/mach/memory.h
> > > > 
> > > >   I'm not sure that I see an easy way to get around this one.
> > > 
> > > ARM_PATCH_PHYS_VIRT should take care of this, have you tried it?
> 
> I believe that this leaves mach-shmobile with three areas
> where CONFIG_MEMORY_START/PLAT_PHYS_OFFSET is used.

Hmm, I just noticed that in fact shmobile is the only remaining
platform that uses CONFIG_MEMORY_START with a per-board or per-soc
setting.

> * arch/arm/mach-shmobile/headsmp.S
> 
>   This uses PLAT_PHYS_OFFSET.
> 
>   I believe this can be replaced with a run-time calculation. Though I
>   haven't thought about the details yet.
> 
> * arch/arm/boot/compressed/head-shmobile.S
> 
>   This makes use of CONFIG_MEMORY_START.
> 
>   This is only used if CONFIG_ZBOOT_ROM is set.
> 
>   I'm unsure if this can be replaced with a run-time calculation or not.
>   But regardless it is only used if CONFIG_ZBOOT_ROM is set, which is not
>   the default at this time.

Right, you can probably make CONFIG_ZBOOT_ROM_MMCIF and
CONFIG_ZBOOT_ROM_SH_MOBILE_SDHI depend on !ARM_PATCH_PHYS_VIRT

> * arch/arm/mach-shmobile/Makefile.boot
> 
>  This makes use of CONFIG_MEMORY_START to set zreladdr.
> 
>  I believe that the solution to this is to make use of CONFIG_AUTO_ZRELADDR.
>  However, it is not yet clear to me how that can be used in conjunction
>  with a uImage.  As I understand it the boot loader on many of our boards,
>  including the Marzen board which is my first target for this work, boot
>  uImage imagess.

If this doesn't work, we probably also need to find a solution to
build multiple uImage files from the same vmlinux when building a
multiplatform kernel.

	Arnd

^ permalink raw reply

* [PATCH 0/4] ARM/dts: Update OMAP5 with address space and interrupts
From: Benoit Cousson @ 2012-10-22 14:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350901328-3525-1-git-send-email-s-guiriec@ti.com>

Hi Seb,

Good work. Thanks for that series.

Just update it with all the acked-by you've got from the TI driver folks
+ the minor comment and I'll pull it in the for_3.8/dts branch.

That's a detail but you should update the subject with "ARM: dts: OMAP5:
XXX" prefix for consistency with the latest naming convention.

Please, Cc the DT list as well.

Regards,
Benoit

On 10/22/2012 12:22 PM, Sebastien Guiriec wrote:
> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can add the address space
> and interrupt line description inside dtsi file for OMAP5. This serie is updating the
> current OMAP5 IP with missing entry.
> 
> It has been tested on OMAP5 with 3.7-audio-display feature tree.
> - MMC is probing and functional
> - TWL6041 probing (GPIO/I2C)
> - booting (UART)
> 
> Sebastien Guiriec (4):
>   ARM/dts: omap5: Update GPIO with address space and interrupt
>   ARM/dts: omap5: Update I2C with address space and interrupts
>   ARM/dts: omap5: Update UART with address space and interrupts
>   ARM/dts: omap5: Update MMC with address space and interrupts
> 
>  arch/arm/boot/dts/omap5.dtsi |   56 +++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 52 insertions(+), 4 deletions(-)
> 

^ permalink raw reply

* [PATCH 2/2] ASoC: Ux500: Control apb clock
From: Ulf Hansson @ 2012-10-22 14:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121022133200.GG4477@opensource.wolfsonmicro.com>

On 22 October 2012 15:32, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Mon, Oct 22, 2012 at 02:32:05PM +0200, Ulf Hansson wrote:
>> From: Ulf Hansson <ulf.hansson@linaro.org>
>>
>> When switching to common clock driver for ux500 this clock needs to
>> be handled as well. Before this clock was internally managed by the
>> clock driver itself.
>
> Applied but why isn't this a deficiency in the common clock
> implementation for the platform?

Good question. :-) Patches have just been sent to Mike Turquette clk
tree for adding the clock lookups.
First, I thought I might wanted to group them all in a series but
decided that splitting them are probably easier to handle.

Kind regards
Ulf Hansson

^ permalink raw reply

* [PATCH 0/8] I2C patches for v3.8 merge window
From: Felipe Balbi @ 2012-10-22 14:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAM=Q2ctS3hxngk5efcvScAdv-2GtH2pHRZoxRhRTiOWmQA-AXw@mail.gmail.com>

Hi,

On Mon, Oct 22, 2012 at 07:36:31PM +0530, Shubhrajyoti Datta wrote:
> On Mon, Oct 22, 2012 at 7:00 PM, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Mon, Oct 22, 2012 at 12:46:50PM +0300, Felipe Balbi wrote:
> >> Hi guys,
> >>
> >> here's another series for OMAP I2C driver. There are a few cleanups
> >> and one very nice new feature: we can now report how many bytes
> >> we transferred until NACK.
> >>
> >> Note that the implemementation for OMAP-I2C turned out to be a
> >> little more complex then I expected, mainly because of the way
> >> I2C_CNT register behaves and because of the very buggy register
> >> usage on that driver.
> >>
> >> I have boot tested all patches on beagle xM (3630) and pandaboard
> >> rev A3 (4430), will send boot-logs if anyone wants to see.
> 
> tested the below branch on omap4430sdp , panda , omap3430sdp.
> 
> Doing simple i2ctools
> .
> 
> Tested-by : Shubhrajyoti D <shubhrajyoti@ti.com>
> 

can you also check if echo mem > /sys/power/state works ? Don't forget
to enable UART wakeups with:

echo enabled > /sys/devices/platform/omap_uart.2/power/wakeup
echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup

before trying to suspend. Another cool test is rtctest (since our RTC is
part of TWL). It worked fine on my two platforms. Attached you will find
the sourcecode for rtctest.

> >> All patches are available at [1] if anyone wants an easy way to
> >> test the patches.
> >>
> >> [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git i2c-transferred-bytes-on-NACK
> >
> > forgot to mention, with [1] I could veridy suspend to ram with boards
> > mentioned above.
> >
> > [1] http://marc.info/?l=linux-arm-kernel&m=135090724817604&w=2
> >
> >> Felipe Balbi (7):
> >>   i2c: omap: no need to access platform_device
> >>   i2c: omap: reorder exit path of omap_i2c_xfer_msg()
> >>   i2c: omap: fix error checking
> >>   i2c: omap: also complete() when stat becomes zero
> >>   i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3
> >>   i2c: omap: wait for transfer completion before sending STP bit
> >>   i2c: omap: implement handling for 'transferred' bytes
> >>
> >> Shubhrajyoti D (1):
> >>   i2c: add 'transferred' field to struct i2c_msg
> >>
> >>  arch/arm/mach-omap2/i2c.c                  |   3 +-
> >>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   2 +-
> >>  drivers/i2c/busses/i2c-omap.c              | 156 ++++++++++++++++-------------
> >>  include/linux/i2c-omap.h                   |   1 +
> >>  include/uapi/linux/i2c.h                   |   1 +
> >>  5 files changed, 89 insertions(+), 74 deletions(-)
> >>
> >> --
> >> 1.8.0.rc0
> >>
> >
> > --
> > balbi

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtctest.c
Type: text/x-csrc
Size: 5768 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/d3212336/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/d3212336/attachment-0001.sig>

^ permalink raw reply

* [PATCH 0/8] I2C patches for v3.8 merge window
From: Shubhrajyoti Datta @ 2012-10-22 14:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121022133023.GC14033@arwen.pp.htv.fi>

On Mon, Oct 22, 2012 at 7:00 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Mon, Oct 22, 2012 at 12:46:50PM +0300, Felipe Balbi wrote:
>> Hi guys,
>>
>> here's another series for OMAP I2C driver. There are a few cleanups
>> and one very nice new feature: we can now report how many bytes
>> we transferred until NACK.
>>
>> Note that the implemementation for OMAP-I2C turned out to be a
>> little more complex then I expected, mainly because of the way
>> I2C_CNT register behaves and because of the very buggy register
>> usage on that driver.
>>
>> I have boot tested all patches on beagle xM (3630) and pandaboard
>> rev A3 (4430), will send boot-logs if anyone wants to see.

tested the below branch on omap4430sdp , panda , omap3430sdp.

Doing simple i2ctools
.

Tested-by : Shubhrajyoti D <shubhrajyoti@ti.com>

>>
>> All patches are available at [1] if anyone wants an easy way to
>> test the patches.
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git i2c-transferred-bytes-on-NACK
>
> forgot to mention, with [1] I could veridy suspend to ram with boards
> mentioned above.
>
> [1] http://marc.info/?l=linux-arm-kernel&m=135090724817604&w=2
>
>> Felipe Balbi (7):
>>   i2c: omap: no need to access platform_device
>>   i2c: omap: reorder exit path of omap_i2c_xfer_msg()
>>   i2c: omap: fix error checking
>>   i2c: omap: also complete() when stat becomes zero
>>   i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3
>>   i2c: omap: wait for transfer completion before sending STP bit
>>   i2c: omap: implement handling for 'transferred' bytes
>>
>> Shubhrajyoti D (1):
>>   i2c: add 'transferred' field to struct i2c_msg
>>
>>  arch/arm/mach-omap2/i2c.c                  |   3 +-
>>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   2 +-
>>  drivers/i2c/busses/i2c-omap.c              | 156 ++++++++++++++++-------------
>>  include/linux/i2c-omap.h                   |   1 +
>>  include/uapi/linux/i2c.h                   |   1 +
>>  5 files changed, 89 insertions(+), 74 deletions(-)
>>
>> --
>> 1.8.0.rc0
>>
>
> --
> balbi

^ permalink raw reply

* [PATCH 5/5] clk: ux500: Register slimbus clock lookups for u8500
From: Ulf Hansson @ 2012-10-22 13:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350914281-1332-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

At the same time the prcc bit for the kclk is corrected to
bit 8 instead of 3.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/clk/ux500/u8500_clk.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index 0aae929..e2c17d1 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -254,6 +254,7 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p1_pclk8", "per1clk", U8500_CLKRST1_BASE,
 				BIT(8), 0);
+	clk_register_clkdev(clk, "apb_pclk", "slimbus0");
 
 	clk = clk_reg_prcc_pclk("p1_pclk9", "per1clk", U8500_CLKRST1_BASE,
 				BIT(9), 0);
@@ -441,8 +442,8 @@ void u8500_clk_init(void)
 	clk_register_clkdev(clk, NULL, "nmk-i2c.2");
 
 	clk = clk_reg_prcc_kclk("p1_slimbus0_kclk", "slimclk",
-			U8500_CLKRST1_BASE, BIT(3), CLK_SET_RATE_GATE);
-	/* FIXME: Redefinition of BIT(3). */
+			U8500_CLKRST1_BASE, BIT(8), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "slimbus0");
 
 	clk = clk_reg_prcc_kclk("p1_i2c4_kclk", "i2cclk",
 			U8500_CLKRST1_BASE, BIT(9), CLK_SET_RATE_GATE);
-- 
1.7.10

^ permalink raw reply related

* [PATCH 4/5] clk: ux500: Update rtc clock lookup for u8500
From: Ulf Hansson @ 2012-10-22 13:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350914281-1332-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/clk/ux500/u8500_clk.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index be843ba..0aae929 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -40,7 +40,7 @@ void u8500_clk_init(void)
 				CLK_IS_ROOT|CLK_IGNORE_UNUSED,
 				32768);
 	clk_register_clkdev(clk, "clk32k", NULL);
-	clk_register_clkdev(clk, NULL, "rtc-pl031");
+	clk_register_clkdev(clk, "apb_pclk", "rtc-pl031");
 
 	/* PRCMU clocks */
 	fw_version = prcmu_get_fw_version();
-- 
1.7.10

^ permalink raw reply related

* [PATCH 3/5] clk: ux500: Register msp clock lookups for u8500
From: Ulf Hansson @ 2012-10-22 13:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350914281-1332-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/clk/ux500/u8500_clk.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index 36ef41d..be843ba 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -232,8 +232,13 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p1_pclk3", "per1clk", U8500_CLKRST1_BASE,
 				BIT(3), 0);
+	clk_register_clkdev(clk, "apb_pclk", "msp0");
+	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.0");
+
 	clk = clk_reg_prcc_pclk("p1_pclk4", "per1clk", U8500_CLKRST1_BASE,
 				BIT(4), 0);
+	clk_register_clkdev(clk, "apb_pclk", "msp1");
+	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.1");
 
 	clk = clk_reg_prcc_pclk("p1_pclk5", "per1clk", U8500_CLKRST1_BASE,
 				BIT(5), 0);
@@ -262,6 +267,8 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p1_pclk11", "per1clk", U8500_CLKRST1_BASE,
 				BIT(11), 0);
+	clk_register_clkdev(clk, "apb_pclk", "msp3");
+	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.3");
 
 	clk = clk_reg_prcc_pclk("p2_pclk0", "per2clk", U8500_CLKRST2_BASE,
 				BIT(0), 0);
@@ -285,6 +292,8 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p2_pclk5", "per2clk", U8500_CLKRST2_BASE,
 				BIT(5), 0);
+	clk_register_clkdev(clk, "apb_pclk", "msp2");
+	clk_register_clkdev(clk, "apb_pclk", "ux500-msp-i2s.2");
 
 	clk = clk_reg_prcc_pclk("p2_pclk6", "per2clk", U8500_CLKRST2_BASE,
 				BIT(6), 0);
@@ -415,8 +424,13 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_kclk("p1_msp0_kclk", "msp02clk",
 			U8500_CLKRST1_BASE, BIT(3), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "msp0");
+	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.0");
+
 	clk = clk_reg_prcc_kclk("p1_msp1_kclk", "msp1clk",
 			U8500_CLKRST1_BASE, BIT(4), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "msp1");
+	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.1");
 
 	clk = clk_reg_prcc_kclk("p1_sdi0_kclk", "sdmmcclk",
 			U8500_CLKRST1_BASE, BIT(5), CLK_SET_RATE_GATE);
@@ -436,6 +450,8 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_kclk("p1_msp3_kclk", "msp1clk",
 			U8500_CLKRST1_BASE, BIT(10), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "msp3");
+	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.3");
 
 	/* Periph2 */
 	clk = clk_reg_prcc_kclk("p2_i2c3_kclk", "i2cclk",
@@ -448,6 +464,8 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_kclk("p2_msp2_kclk", "msp02clk",
 			U8500_CLKRST2_BASE, BIT(3), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "msp2");
+	clk_register_clkdev(clk, NULL, "ux500-msp-i2s.2");
 
 	clk = clk_reg_prcc_kclk("p2_sdi1_kclk", "sdmmcclk",
 			U8500_CLKRST2_BASE, BIT(4), CLK_SET_RATE_GATE);
-- 
1.7.10

^ permalink raw reply related

* [PATCH 2/5] clk: ux500: Register ssp clock lookups for u8500
From: Ulf Hansson @ 2012-10-22 13:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350914281-1332-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/clk/ux500/u8500_clk.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index 7ad01aa..36ef41d 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -321,8 +321,11 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p3_pclk1", "per3clk", U8500_CLKRST3_BASE,
 				BIT(1), 0);
+	clk_register_clkdev(clk, "apb_pclk", "ssp0");
+
 	clk = clk_reg_prcc_pclk("p3_pclk2", "per3clk", U8500_CLKRST3_BASE,
 				BIT(2), 0);
+	clk_register_clkdev(clk, "apb_pclk", "ssp1");
 
 	clk = clk_reg_prcc_pclk("p3_pclk3", "per3clk", U8500_CLKRST3_BASE,
 				BIT(3), 0);
@@ -465,8 +468,11 @@ void u8500_clk_init(void)
 	/* Periph3 */
 	clk = clk_reg_prcc_kclk("p3_ssp0_kclk", "sspclk",
 			U8500_CLKRST3_BASE, BIT(1), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "ssp0");
+
 	clk = clk_reg_prcc_kclk("p3_ssp1_kclk", "sspclk",
 			U8500_CLKRST3_BASE, BIT(2), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "ssp1");
 
 	clk = clk_reg_prcc_kclk("p3_i2c0_kclk", "i2cclk",
 			U8500_CLKRST3_BASE, BIT(3), CLK_SET_RATE_GATE);
-- 
1.7.10

^ permalink raw reply related

* [PATCH 1/5] clk: ux500: Register i2c clock lookups for u8500
From: Ulf Hansson @ 2012-10-22 13:57 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1350914281-1332-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
 drivers/clk/ux500/u8500_clk.c |   19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/ux500/u8500_clk.c b/drivers/clk/ux500/u8500_clk.c
index ca4a25e..7ad01aa 100644
--- a/drivers/clk/ux500/u8500_clk.c
+++ b/drivers/clk/ux500/u8500_clk.c
@@ -228,6 +228,8 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p1_pclk2", "per1clk", U8500_CLKRST1_BASE,
 				BIT(2), 0);
+	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.1");
+
 	clk = clk_reg_prcc_pclk("p1_pclk3", "per1clk", U8500_CLKRST1_BASE,
 				BIT(3), 0);
 	clk = clk_reg_prcc_pclk("p1_pclk4", "per1clk", U8500_CLKRST1_BASE,
@@ -239,6 +241,7 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p1_pclk6", "per1clk", U8500_CLKRST1_BASE,
 				BIT(6), 0);
+	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.2");
 
 	clk = clk_reg_prcc_pclk("p1_pclk7", "per1clk", U8500_CLKRST1_BASE,
 				BIT(7), 0);
@@ -255,11 +258,14 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_pclk("p1_pclk10", "per1clk", U8500_CLKRST1_BASE,
 				BIT(10), 0);
+	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.4");
+
 	clk = clk_reg_prcc_pclk("p1_pclk11", "per1clk", U8500_CLKRST1_BASE,
 				BIT(11), 0);
 
 	clk = clk_reg_prcc_pclk("p2_pclk0", "per2clk", U8500_CLKRST2_BASE,
 				BIT(0), 0);
+	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.3");
 
 	clk = clk_reg_prcc_pclk("p2_pclk1", "per2clk", U8500_CLKRST2_BASE,
 				BIT(1), 0);
@@ -284,7 +290,6 @@ void u8500_clk_init(void)
 				BIT(6), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi1");
 
-
 	clk = clk_reg_prcc_pclk("p2_pclk7", "per2clk", U8500_CLKRST2_BASE,
 				BIT(7), 0);
 	clk_register_clkdev(clk, "apb_pclk", "sdi3");
@@ -318,8 +323,10 @@ void u8500_clk_init(void)
 				BIT(1), 0);
 	clk = clk_reg_prcc_pclk("p3_pclk2", "per3clk", U8500_CLKRST3_BASE,
 				BIT(2), 0);
+
 	clk = clk_reg_prcc_pclk("p3_pclk3", "per3clk", U8500_CLKRST3_BASE,
 				BIT(3), 0);
+	clk_register_clkdev(clk, "apb_pclk", "nmk-i2c.0");
 
 	clk = clk_reg_prcc_pclk("p3_pclk4", "per3clk", U8500_CLKRST3_BASE,
 				BIT(4), 0);
@@ -401,6 +408,8 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_kclk("p1_i2c1_kclk", "i2cclk",
 			U8500_CLKRST1_BASE, BIT(2), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "nmk-i2c.1");
+
 	clk = clk_reg_prcc_kclk("p1_msp0_kclk", "msp02clk",
 			U8500_CLKRST1_BASE, BIT(3), CLK_SET_RATE_GATE);
 	clk = clk_reg_prcc_kclk("p1_msp1_kclk", "msp1clk",
@@ -412,17 +421,23 @@ void u8500_clk_init(void)
 
 	clk = clk_reg_prcc_kclk("p1_i2c2_kclk", "i2cclk",
 			U8500_CLKRST1_BASE, BIT(6), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "nmk-i2c.2");
+
 	clk = clk_reg_prcc_kclk("p1_slimbus0_kclk", "slimclk",
 			U8500_CLKRST1_BASE, BIT(3), CLK_SET_RATE_GATE);
 	/* FIXME: Redefinition of BIT(3). */
+
 	clk = clk_reg_prcc_kclk("p1_i2c4_kclk", "i2cclk",
 			U8500_CLKRST1_BASE, BIT(9), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "nmk-i2c.4");
+
 	clk = clk_reg_prcc_kclk("p1_msp3_kclk", "msp1clk",
 			U8500_CLKRST1_BASE, BIT(10), CLK_SET_RATE_GATE);
 
 	/* Periph2 */
 	clk = clk_reg_prcc_kclk("p2_i2c3_kclk", "i2cclk",
 			U8500_CLKRST2_BASE, BIT(0), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "nmk-i2c.3");
 
 	clk = clk_reg_prcc_kclk("p2_sdi4_kclk", "sdmmcclk",
 			U8500_CLKRST2_BASE, BIT(2), CLK_SET_RATE_GATE);
@@ -452,8 +467,10 @@ void u8500_clk_init(void)
 			U8500_CLKRST3_BASE, BIT(1), CLK_SET_RATE_GATE);
 	clk = clk_reg_prcc_kclk("p3_ssp1_kclk", "sspclk",
 			U8500_CLKRST3_BASE, BIT(2), CLK_SET_RATE_GATE);
+
 	clk = clk_reg_prcc_kclk("p3_i2c0_kclk", "i2cclk",
 			U8500_CLKRST3_BASE, BIT(3), CLK_SET_RATE_GATE);
+	clk_register_clkdev(clk, NULL, "nmk-i2c.0");
 
 	clk = clk_reg_prcc_kclk("p3_sdi2_kclk", "sdmmcclk",
 			U8500_CLKRST3_BASE, BIT(4), CLK_SET_RATE_GATE);
-- 
1.7.10

^ permalink raw reply related

* [PATCH 0/5] clk: ux500: Add clock lookups for u8500
From: Ulf Hansson @ 2012-10-22 13:57 UTC (permalink / raw)
  To: linux-arm-kernel

From: Ulf Hansson <ulf.hansson@linaro.org>

Step by step, clock lookups for u8500 are being added in this set
of patches.

These patches will require additional patches for sound/soc/ux500/
driver as well as drivers/i2c/busses/i2c-nomadik driver to prevent
the boot for ux500 from break. Those patches are being merged through
separate trees.

Ulf Hansson (5):
  clk: ux500: Register i2c clock lookups for u8500
  clk: ux500: Register ssp clock lookups for u8500
  clk: ux500: Register msp clock lookups for u8500
  clk: ux500: Update rtc clock lookup for u8500
  clk: ux500: Register slimbus clock lookups for u8500

 drivers/clk/ux500/u8500_clk.c |   50 +++++++++++++++++++++++++++++++++++++----
 1 file changed, 46 insertions(+), 4 deletions(-)

-- 
1.7.10

^ permalink raw reply

* [PATCH 3/4] ARM/dts: omap5: Update UART with address space and interrupts
From: Sourav @ 2012-10-22 13:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <50854273.5080504@ti.com>


Hi Sebestien,
On Monday 22 October 2012 06:26 PM, Sourav wrote:
> On Monday 22 October 2012 06:20 PM, Benoit Cousson wrote:
>> On 10/22/2012 02:27 PM, Sourav wrote:
>>> Hi Benoit,
>>> On Monday 22 October 2012 05:37 PM, Benoit Cousson wrote:
>>>> On 10/22/2012 01:57 PM, Benoit Cousson wrote:
>>>>> Hi Sourav,
>>>>>
>>>>> On 10/22/2012 01:16 PM, Sourav wrote:
>>>>>> Hi Sebastien,
>>>>>> On Monday 22 October 2012 03:52 PM, Sebastien Guiriec wrote:
>>>>>>> Add base address and interrupt line inside Device Tree data for
>>>>>> Incomplete sentence!
>>>>>>> Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
>>>>>>> ---
>>>>>>>     arch/arm/boot/dts/omap5.dtsi |   16 ++++++++++++++--
>>>>>>>     1 file changed, 14 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/omap5.dtsi
>>>>>>> b/arch/arm/boot/dts/omap5.dtsi
>>>>>>> index 6c22e1b..413df94 100644
>>>>>>> --- a/arch/arm/boot/dts/omap5.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/omap5.dtsi
>>>>>>> @@ -237,36 +237,48 @@
>>>>>>>               uart1: serial at 4806a000 {
>>>>>>>                 compatible = "ti,omap4-uart";
>>>>>>> +            reg = <0x4806a000 0x100>;
>>>>>>> +            interrupts = <0 72 0x4>;
>>>>>>>                 ti,hwmods = "uart1";
>>>>>>>                 clock-frequency = <48000000>;
>>>>>>>             };
>>>>>>>               uart2: serial at 4806c000 {
>>>>>>>                 compatible = "ti,omap4-uart";
>>>>>>> +            reg = <0x4806c000 0x100>;
>>>>>>> +            interrupts = <0 73 0x4>;
>>>>>>>                 ti,hwmods = "uart2";
>>>>>>>                 clock-frequency = <48000000>;
>>>>>>>             };
>>>>>>>               uart3: serial at 48020000 {
>>>>>>>                 compatible = "ti,omap4-uart";
>>>>>>> +            reg = <0x48020000 0x100>;
>>>>>>> +            interrupts = <0 74 0x4>;
>>>>>>>                 ti,hwmods = "uart3";
>>>>>>>                 clock-frequency = <48000000>;
>>>>>>>             };
>>>>>>>               uart4: serial at 4806e000 {
>>>>>>>                 compatible = "ti,omap4-uart";
>>>>>>> +            reg = <0x4806e000 0x100>;
>>>>>>> +            interrupts = <0 70 0x4>;
>>>>>>>                 ti,hwmods = "uart4";
>>>>>>>                 clock-frequency = <48000000>;
>>>>>>>             };
>>>>>>>               uart5: serial at 48066000 {
>>>>>>> -            compatible = "ti,omap5-uart";
>>>>>>> +            compatible = "ti,omap4-uart";
>>>>>>> +            reg = <0x48066000 0x100>;
>>>>>>> +            interrupts = <0 105 0x4>;
>>>>>> In Omap5 TRM, the interrupt number mentioned for uart5 is 138. 
>>>>>> How is
>>>>>> 105 coming?
>>>>> It is from hwmod and thus from the HW spec. It looks like the TRM is
>>>>> wrong... or the HW spec :-)
>>>>>
>>>>>>>                 ti,hwmods = "uart5";
>>>>>>>                 clock-frequency = <48000000>;
>>>>>>>             };
>>>>>>>               uart6: serial at 48068000 {
>>>>>>> -            compatible = "ti,omap6-uart";
>>>>>>> +            compatible = "ti,omap4-uart";
>>>>>>> +            reg = <0x48068000 0x100>;
>>>>>>> +            interrupts = <0 106 0x4>;
>>>>>> Same here, TRM shows this number to be 139 ?
>>>> In fact, even the TRM (ES1.0 NDA vM) is aligned with these data.
>>>> Where did you see 138 and 139?
>>> I looked at Page 6300 of the above TRM, Figure 24-60. Is this place not
>>> correct to look
>>> up for these data?
>> Nope. Well it should be accurate but since it is a diagram, it does not
>> necessarily reflect the latest integration data like IRQ line.
>>
>> You'd better use the table that list all the IRQ per CPU:
>>
>> 18.3.2 Interrupt Requests to INTC_MPU
> Ahh. True. The table does show the numbers to be 105 and 106.
> Thanks for the pointer.
>
> ~Sourav
>> Regards,
>> Benoit
>>
>
After fixing the minor comment on the commit log, you can add

Acked-by: Sourav Poddar <sourav.poddar@ti.com>

>
> _______________________________________________
> 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] clk: Make the generic clock API available by default
From: Mark Brown @ 2012-10-22 13:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121022135024.GN21164@n2100.arm.linux.org.uk>

On Mon, Oct 22, 2012 at 02:50:24PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 22, 2012 at 02:27:11PM +0100, Mark Brown wrote:

> > If we're worrying about that there's the larger point that the effect of
> > this patch is to make HAVE_CLK meaningless as there will be no platform
> > for which it's not true.  I was just leaving HAVE_CLK alone for now
> > ready to circle around on it if we ever manage to get the enabling bit
> > sorted.

> Are you sure that all architectures are fine with having that permanently
> enabled?  What about nommu architectures?

There's already stubs present so the main use case for depending on it
(checking if code can build) is already covered without requiring that
the API actually be built on all platforms.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/9983472a/attachment-0001.sig>

^ permalink raw reply

* [PATCH 2/3] PWM: vt8500: Update vt8500 PWM driver support
From: Arnd Bergmann @ 2012-10-22 13:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121022120706.GA19467@avionic-0098.mockup.avionic-design.de>

On Monday 22 October 2012, Thierry Reding wrote:
> > As long as we get build warnings for leaving out the __devinit/__devexit
> > annotations, I would generally recommend putting them in. If we do a
> > patch to remove all of them, a couple extra instances will not cause
> > any more troubles than we already have.
> 
> I've never seen any build warnings for leaving __devinit/__devexit out.
> Where does that happen?

Section mismatches usually result into warnings from modpost, like

WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

Actually doing that gives you an output like this (currently on exynos_defconfig):

$ make CONFIG_DEBUG_SECTION_MISMATCH=y
WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in reference from the function samsung_pinctrl_probe() to the function .init.text:samsung_gpiolib_register()
The function __devinit samsung_pinctrl_probe() references
a function __init samsung_gpiolib_register().
If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
annotate samsung_gpiolib_register with a matching annotation.

or like this (now fixed in socfpga_defconfig):

WARNING: drivers/net/ethernet/stmicro/stmmac/stmmac.o(.text+0x5d4c): Section mismatch in reference from the function stmmac_pltfr_probe() to the function .devinit.text:stmmac_probe_config_dt()
The function stmmac_pltfr_probe() references
the function __devinit stmmac_probe_config_dt().
This is often because stmmac_pltfr_probe lacks a __devinit 
annotation or the annotation of stmmac_probe_config_dt is wrong.

I believe you normally don't get warnings for functions that could be
marked __devinit and only call regular functions, but there are
a couple of __devinit infrastructure functions that you can't call
from a function that isn't __init or __devinit.

	Arnd

^ permalink raw reply

* [PATCH] clk: Make the generic clock API available by default
From: Russell King - ARM Linux @ 2012-10-22 13:50 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121022132711.GE4477@opensource.wolfsonmicro.com>

On Mon, Oct 22, 2012 at 02:27:11PM +0100, Mark Brown wrote:
> On Mon, Oct 22, 2012 at 02:05:57PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 22, 2012 at 02:02:50PM +0100, Mark Brown wrote:
> > > @@ -327,6 +328,7 @@ config ARCH_AT91
> > >  	select ARCH_REQUIRE_GPIOLIB
> > >  	select CLKDEV_LOOKUP
> > >  	select HAVE_CLK
> > > +	select HAVE_CUSTOM_CLK
> 
> > This is silly.  If you select "HAVE_CUSTOM_CLK" then isn't it true that
> > "HAVE_CLK" should also be selected?  If so, why not have "HAVE_CUSTOM_CLK"
> > do that selection and remove it from all these entries?
> 
> If we're worrying about that there's the larger point that the effect of
> this patch is to make HAVE_CLK meaningless as there will be no platform
> for which it's not true.  I was just leaving HAVE_CLK alone for now
> ready to circle around on it if we ever manage to get the enabling bit
> sorted.

Are you sure that all architectures are fine with having that permanently
enabled?  What about nommu architectures?

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox